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

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

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

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

Ответы

Ответ 1

Ответы на каждую из точек.

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

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

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