Рубрики
Uncategorized

(Основная анатомия PHP7-1) CGI и FastCGI

Автор оригинала: David Wong.

CGI: Протокол для обмена данными между веб-сервером и веб-приложением. FastCGI: С CGI это протокол связи, но он более эффективен, чем CGI. PHP-CGI: Это программа интерфейса протокола CGI, предоставляемая PHP (веб-приложением) веб-серверу. PHP-FPM: Программа интерфейса протокола FastCGI, предоставляемая PHP (веб-приложением) веб-серверу. Он также обеспечивает относительно интеллектуальное управление задачами.

Рабочий процесс CGI

1. Если клиент запрашивает индекс. html, веб-сервер найдет файл в файловой системе и отправит его в браузер, где распространяются статические данные.

2. Когда веб-сервер получает запрос индекса. php , он запустит соответствующую программу CGI, которая является синтаксическим анализатором PHP. Затем анализатор PHP анализирует файл php.ini, инициализирует среду выполнения, обрабатывает запросы, возвращает обработанные результаты в формате, указанном CGI, завершает процесс, и веб-сервер возвращает результаты в браузер.

Рабочий процесс FastCGI

1. Если клиент запрашивает индекс. html, веб-сервер найдет файл в файловой системе и отправит его в браузер, где распространяются статические данные.

2. Когда веб-сервер получает запрос на index.php, программа FastCGI (FastCGI инициализирует среду выполнения при запуске, и каждый пул процессов CGI совместно использует среду выполнения) выбирает процесс CGI в пуле процессов CGI для обработки запроса, а затем возвращает обработанный результат в формате, указанном CGI, и ожидает следующего. Запрос.

Базовая реализация PHP-FPM

1. Реализация PHP-FPM заключается в создании главного процесса, создании рабочего пула в главном процессе и предоставлении ему возможности прослушивать сокеты, а затем раскошелиться на несколько подпроцессов (работа). Эти подпроцессы соответственно принимают запросы. Обработка подпроцессов очень проста. Он блокируется при принятии после запуска и начинает считывать данные запроса после поступления запроса. Обработка начинается после считывания, а затем возвращается. В течение этого периода никаких других запросов получено не будет. Другими словами, подпроцесс PHP-FPM может одновременно отвечать только на один запрос и принимать следующий запрос только после завершения обработки запроса.

2. Основной процесс PHP-FPM не взаимодействует напрямую с рабочим процессом. Мастер получает информацию о рабочем процессе через общую память, такую как текущее состояние рабочего процесса, количество обработанных запросов и т.д. Когда главный процесс хочет убить рабочий процесс, он уведомляет рабочий процесс, посылая сигналы.

3. PHP-FPM может контролировать несколько портов одновременно, каждый порт соответствует рабочему пулу, а каждый пул соответствует нескольким рабочим процессам.

Рабочий процесс

1. Ожидание запросов: рабочий процесс заблокирован в fcgi_accept_request() в ожидании запросов; 2. анализ запросов: запросы fastcgi принимаются работником после прибытия, а затем начинают получать и анализировать данные запроса до тех пор, пока данные запроса не поступят полностью; 3. Инициализация запроса: выполните php_request_startup (), который вызывает каждое расширение: PHP_RINIT_FUNCTION(); 4. Компиляция и выполнение: PHP-скрипт компилируется и выполняется php_execute_script(). 5. Закройте запрос: После завершения запроса выполните php_request_shutdown(), который вызывает каждое расширение: PHP_RSHUTDOWN_FUNCTION(), а затем переходит к шагу (1), чтобы дождаться следующего запроса.

Управление основными процессами

1. Статический: Этот метод относительно прост. При запуске мастер настраивает вилку в соответствии с конфигурацией pm.max_children для создания соответствующего количества рабочих процессов, то есть количество рабочих процессов является фиксированным и неизменным.

2. Динамический: Динамическое управление процессами. Во-первых, определенное количество работников инициализируется в соответствии с pm. start_servers при запуске FPM. Во время работы, если мастер обнаружит, что количество незанятых рабочих меньше, чем количество конфигураций pm. min_spare_servers (что означает, что работник не может обработать больше запросов), он разветвит рабочий процесс, но общее количество рабочих не может превышать pm.ma. X_children, если мастер обнаружит, что количество незанятых работников превышает pm.max_spare_servers (что указывает на слишком большое количество незанятых работников), он убьет некоторых работников и не будет занимать слишком много ресурсов. Мастер контролирует количество работников с помощью этих четырех значений

3. по требованию: Этот метод используется редко. Рабочий процесс не выделяется при запуске, и рабочий процесс вилки главного процесса получает уведомление при поступлении запроса. Общее число работников не превышает pm.max_children. Рабочий процесс не завершится сразу после завершения обработки, и он завершится после того, как время простоя превысит pm.process_idle_time.

Менеджер событий PHP-FPM

1. Событие для чтения в конвейере sp [1]: Это событие используется мастером для обработки сигналов

2. fpm_pctl_perform_idle_server_maintenance_heartbeat(): Это главное событие реализации управления процессами. Мастер запускает таймер и запускает его каждые 1 сек. Он в основном используется для управления рабочими в динамическом режиме и по требованию. Мастер регулярно проверяет количество рабочих процессов в каждом рабочем пуле и реализует номер работника с помощью этого таймера. Контроль количества

3. fpm_pctl_heartbeat(): Это событие используется для ограничения максимального времени, затрачиваемого работником на обработку одного запроса. php-fpm.conf содержит элемент конфигурации request_terminate_timeout. Если работник обрабатывает запрос в течение более чем этого общего времени, мастер отправит рабочий процесс сигнал об остановке, чтобы остановить рабочий процесс, и это приведет к остановке рабочего процесса. Единица измерения конфигурации-секунды, а значение по умолчанию-0, чтобы отключить этот механизм.

4. fpm_pctl_on_socket_accept(): События, когда поступает новый запрос для главного мониторинга в режиме ondemand, поскольку FPM в режиме ondemand не создает предварительно работника при запуске и генерирует подпроцесс при наличии запроса, необходимо уведомить главный процесс о поступлении запроса.