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

Question

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

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

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

Answer 1

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

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

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

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