Что было нового в версии 3.0:

1. Поддержка питона 3.1 и выше.
2. Опции «process-group», «application-group», «callable-object» и «pass-authorization» могут быть размещены в директивах WSGIscriptAlias и WSGIscriptAliasMatch
3. Если клиент обрывает соединение в процессе обработки итератора вместо «бросания исключения» теперь записывается отладочное сообщение в лог
4. В директиву WSGIDaemonProcess добавлена опция «chroot», позволяющая запускать приложения более изолированно
5. Добавлена глобальная директива WSGIPy3kWarningFlag, при использовании python2.6 будут выдаваться предупреждения
6. Исправлена «assertion error» если питон был скомпилирован с директивой Py_DEBUG
7. Добавлена поддержка «Content-Type: chunked» в запросе (директива «WSGIChunkedRequest»). Данные склеиваются и передаются приложению на обработку.
8. Значения HTTP заголовков теперь передаются в справочнике окружения, для хуков доступа, авторизации и аутентификации
9. Флаг «flag wsgi.run_once» не выставляется в True, при работе в режиме демона, когда «maximum-requests» установлен в 1. В случае использования множества потоков, параметр «maximum-requests» проверяется только после завершения обработки запроса, поэтому нет гарантии, был ли выполнен только один запрос
10. Теперь интерпретаор инициализируется не в родительском процессе, а только после того, как будет создан дочерний
11. Сообщения из модулей-расширений на C попадают в логи виртуальных хостов, как и положено, а не в общий лог, как было ранее
12. Теперь невозможно писать сообщения в логи «чужих» виртуальных хостов
13. В режиме демона может производиться внутренняя переадресация с использоваением заголовка «Location» в ответе
14. В режиме демона может использоваться директива «WSGIErrorOverride», для того, чтобы возвращать стандартные страница ошибок Apache
15. Добавлена директива «WSGIPythonWarnings» работающая по аналогии с директивой «-W» интерпретатора
16. В директиву «WSGIDaemonProcess» добавлена опция «cpu-time-limit» определяющая количество процессорного времени, после которого процесс будет перезапущен
17. В директиву «WSGIDaemonProcess» добавлена опция «cpu-priority» говорящая за себя
18. Добавлена директива «WSGIHandlerscript» позволяющая определить скрипт, обрабатывающий определённый тип файлов

И ещё множество исправлений и улучшений, о которых можно почитать в оригинале тут: code.google.com/p/modwsgi/wiki/ChangesInVersion0301

Скачать, как обычно можно тут:
code.google.com/p/modwsgi/downloads/list

UPD:
Да, всё работает
./configure --with-python=python3.1 --disable-framework
make && sudo make install

Здрасти. Долго-долго я присматривался к замечательному фреймворку django, читал книгу, изучал статьи, пробовал писать hello world'ы (со встроенным в джангу сервером это было легко и приятно). А вчера я попробовал настроить от начала до конца боевой сервер, и как оказалось, это не так просто, и мне даже показалось, что будь я моложе и неопытнее, я бы плюнул на это дело. Вот я и решил поделиться с читателями полной инструкцией, снабдив её некоторыми рассуждениями и конфигами. Статья расчитана на начинающих, но будет интересно всем, обещаю.

Долго откладывал разобраться, так и релоадил апач целиком :)

@never_cache
def restart(request):
    ''' Перезапуск демона '''
    if request.META['mod_wsgi.process_group'] != '':
        import signal, os
        os.kill(os.getpid(), signal.SIGINT)
        ret = 'restarted'
    else:
        ret = 'not find porcess_group'
        
    return HttpResponse(ret, mimetype='text/plain')

UP: touch yourfile.wsgi

В предыдущей части мы начали бороться за память на 256 мегабайтном слайсе «на скорую руку». Результат был, но не столь эффектный как тот которого я добился на этот раз.

Я всегда догадывался, что причина всех моих неприятностей — apache. И чем больше я пытался его настраивать, тем больше в этом убеждался. Вывод? Попробовать заменить. Одно но — переход должен быть как можно более плавным, поскольку речь, ясно дело, о продакшене.

Поскольку у меня был опыт общения с nginx, а если быть точным — опыт с проксированием, то был выбран именно этот веб-сервер. К тому же у него хорошие параметры производительности.

Какое-то время назад потребовалось перенести проекты с выделенного сервера на VPS. Для этих целей был выбран slicehost. В общем и целом контора нравится и готов её рекомендовать всем.

Случилась лишь одна проблема: начали приходить уведомления о слишком сильном использовании диска (чтение/запись). Долгое время проблема не находила решения из-за отсутствия времени, но это вылилось в непонятные отказы, сопровождавшиеся статистикой в >200% CPU usage. После долгих извращений, была найдена проблема, а затем и её решение.