Назад | Перейти на главную страницу

mod_wsgi: разделять процессы демона между vhosts

У меня много сайтов, каждый из которых использует одни и те же 5 приложений Django (с локальными настройками), размещенных на Apache. В настоящее время каждое приложение сайта имеет свою собственную конфигурацию, а именно:

WSGIDaemonProcess api_example threads=15 maximum-requests=2000
WSGIProcessGroup api_example
WSGIScriptAlias /api /var/www/sites/example/api/site.wsgi

Можно ли использовать демоны между vhosts, но оставить локальные настройки активными? Моя цель - сэкономить память и уменьшить количество процессов Apache, запускаемых для запросов на обслуживание (некоторые из этих приложений являются консолями управления / поддержки, которые используются только изредка).

-- редактировать --

Как излагает здесь Грэм Дамплтон: mod_wsgi daemon mode - WSGIDaemonProcess для каждой конфигурации виртуального хоста?, должна быть возможность «связаться с определением процесса демона на предыдущем виртуальном хосте, если [у него] то же имя сервера». Обратите внимание, что, как указывает Грэм, директиву WSGIApplicationGroup необходимо изменить со значения по умолчанию, вероятно, на% {GLOBAL} или% {ENV: variable}.

Я не уверен, как «использовать» объявления на уровне сервера внутри vhost. Можно ли использовать демон серверного уровня с локальными настройками?

Ответ на вышеуказанные вопросы, кратко изложенный как:

  1. Можно ли использовать демоны wsgi между vhosts?
  2. Можно ли сохранить каждое приложение в каждом виртуальном хосте отдельно (при совместном использовании демонов), чтобы локальные настройки были в силе?
  3. если возможны 1. и 2. можно ли перезапустить / выключить демонов для экономии памяти?

Ответ на все вышеперечисленное: да.

Вот пример конфигурации с использованием конфигурации Debian apache2 в качестве примера:

...
# Include definition of wsgi_daemons above the vhost configs
Include /etc/apache2/wsgi_daemons/

# Include the virtual host configurations:
Include /etc/apache2/sites-enabled/
...

Определите несколько демонов wsgi, например:

WSGIDaemonProcess wsgi_support threads=5 \
display-name=wsgi_support inactivity-timeout=600

В вашей конфигурации vhost определите блок в следующих строках:

<Location /support/console>
    WSGIProcessGroup wsgi_support
    WSGIApplicationGroup <this_vhost>_support
    # WSGIApplicationGroup %{GLOBAL} does not work!!!
</Location>
WSGIScriptAlias /support/ /var/www/<this_vhost>/support/site.wsgi

Что это значит:

  • Демон с именем "wsgi_support" будет запущен при запуске / перезапуске Apache.
  • когда <this_vhost>доступ к приложению поддержки, оно будет подключено к процессу демона wsgi_support, как это определено директивой WSGIProcessGroup
  • Чтобы гарантировать, что <this_vhosts>копия приложения работает в собственном пространстве имен (что жизненно важно, если вы, например, запускаете приложения Django, потому что параметры оцениваются только при запуске), vhost предоставляется собственная группа WSGIApplicationGroup. Это заставляет главный демон порождать субинтерпретатор для <this_vhost>приложение.
  • Наконец, директива тайм-аута заставляет демон перезапускаться после указанного периода бездействия, освобождая память, используемую субинтерпретаторами. Это идеально подходит для малоиспользуемых приложений, таких как консоли поддержки.

Пожалуйста, прочтите отличную документацию на http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives.

Изначально меня сбили с толку две вещи: не определить wsgi_daemons в нужном месте (что было довольно глупо) и не осознавать, что директивы WSGIProcessGroup указывают на определения WSGIDaemonProcess.