Взаимодействие Apache + mod wsgi

прежде чем опубликовать это, я прочитал довольно много ресурсов в интернете, включая mod_wsgi wiki, но я смущен тем, как именно процессы/потоки Apache взаимодействуют с mod_wsgi.

Это мое текущее понимание: Apache можно настроить так, чтобы один или несколько дочерних процессов могли обрабатывать входящие запросы, и каждый из этих дочерних процессов может быть настроен на использование одного или нескольких потоков для запросов на обслуживание. После этого вещи начинают получать туманно для меня. Мои сомнения:

  1. что такое WSGIDaemonProcess, и кто на самом деле вызывает мое приложение Django с помощью интерпретатора Python?
  2. если у меня есть приложение Django, работающее в режиме, в котором разрешено несколько потоков в одном дочернем процессе Apache , означает ли это, что несколько запросов могут одновременно обращаться к моему приложению одновременно? Если да - будет ли что-то вроде установки переменной уровня модуля (скажем, идентификатора пользователя) может быть перезаписано другими параллельными запросами и приводят к небезопасному поведению?
  3. для случая выше, с блокировкой глобального интерпретатора Python, будут ли потоки фактически выполняться параллельно?

1 ответов


ответы на каждый из пунктов.

1-WSGIDaemonProcess / WSGIProcessGroup указывают, что mod_wsgi должен вилка отдельного процесса для запуска приложения WSGI В. Это только вилка, а не fork/exec, поэтому mod_wsgi все еще контролирует ее. Когда обнаружено, что URL-адрес сопоставляется с приложением WSGI, запущенным в режиме демона, код mod_wsgi в процессах Apache child worker будет прокси-запрос детали через процесс режима демона, где код mod_wsgi там читает его и вызывает в ваше приложение WSGI.

2-Да, несколько запросов могут работать одновременно и хотят одновременно изменять глобальные данные модуля.

3-в то время, когда выполнение находится внутри самого Python, тогда нет, они не работают строго параллельно, поскольку глобальная блокировка интерпретатора означает, что только один поток может выполнять код Python одновременно. Интерпретатор Python будет периодически переключаться, какой поток запускается. Если один из потоков вызывает код C и освобождает GIL, то, по крайней мере, на время, когда этот поток находится в этом состоянии, он может работать параллельно с другими потоками, работающими в Python или C-коде. Например, когда вызовы выполняются в слой Apache / mod_wsgi для записи данных ответа, Gil освобождается. Это означает, что фактическая запись данных ответа на нижних уровнях не препятствует запуску других потоков.