Notas de lectura de análisis del kernel PHP7 2 (Fpm)
Para continuar con la parte del caso de SAPI del artículo anterior, este artículo solo guarda las notas de Fpm
VACA
Fpm
Fpm (FastCGI Process Manager) es un administrador de procesos del modo operativo PHP FastCGI. De su definición, se puede ver que la función principal de Fpm es la administración de procesos. Entonces, ¿qué proceso se usa para administrar? Esta pregunta debe comenzar con FastCGI.
Introducción a FastCGI
FastCGI es un protocolo de comunicación entre servidores web (como Nignx, Apache) y programas de procesamiento, es un protocolo de comunicación de capa de aplicación similar a HTTP. Nota: es solo un acuerdo.
Una descripción general simple del procesamiento de PHP de solicitudes HTTP a través de FastCGI
PHP es solo un analizador de secuencias de comandos. Puede ser relativamente simple en el modo Cli. Puede pasar comandos directamente a PHP para su procesamiento, pero no puede procesar solicitudes HTTP directamente. PHP implementa el protocolo FastCGI. Para procesar, el servidor web procesa el Solicitud HTTP, y luego reenvía el resultado analizado al programa de procesamiento a través del protocolo FastCGI. Una vez completado el programa de procesamiento, el resultado se devuelve al servidor web y el servidor web vuelve al usuario. Como se muestra abajo
Ampliación de conocimientos: modo de procesamiento de red
PHP implementa el procesamiento del protocolo FastCGI, pero no implementa un procesamiento de red específico Hay dos modelos de procesamiento de red de uso común.
Modo multiproceso : Consiste en un proceso principal y múltiples subprocesos. El proceso principal es responsable de administrar los subprocesos. Los eventos básicos de la red son manejados por cada subproceso. Nginx usa este modelo.
Modelo de subprocesos múltiples : similar a los subprocesos, excepto que es una granularidad de subprocesos. Este modo generalmente es monitoreado por el subproceso principal, recibiendo solicitudes y luego entregado a los subprocesos para su procesamiento. Memcached es este modo; algunos También use el modo multiproceso: el subproceso principal solo es responsable de administrar los subprocesos y no procesar los eventos de la red. Cada subproceso monitorea, recibe y procesa solicitudes. Este modo se usa cuando memcached usa el protocolo UDP.
La diferencia entre proceso y subproceso : el proceso tiene espacio de direcciones y recursos independientes, pero el subproceso no, el espacio de direcciones y los recursos del proceso se comparten entre subprocesos, por lo que el modelo multiproceso es relativamente simple en la administración de recursos, mientras que el El modelo de subprocesos debe considerar diferentes subprocesos El conflicto entre recursos, es decir, la seguridad de subprocesos.
Realización básica
Fpm es un modelo multiproceso , que consta de un proceso maestro y múltiples procesos de trabajo. Cuando se inicia el proceso maestro, crea un socket, pero no acepta ni procesa la solicitud. En su lugar, el proceso hijo trabajador de la bifurcación completa la solicitud.
El trabajo principal del proceso maestro y el proceso de trabajo.
El trabajo principal del proceso maestro es administrar el proceso de trabajo, bifurcar y matar el proceso de trabajo. Por ejemplo, si la solicitud actual tiene demasiados procesos de trabajo para manejar, el proceso maestro intentará bifurcar un nuevo proceso de trabajo para procesar , y cuando hay más procesos de trabajo inactivos, matará algunos procesos secundarios para evitar ocupar y desperdiciar recursos del sistema. El trabajo principal del
proceso de trabajo es procesar la solicitud. Cada proceso de trabajo competirá por la solicitud de aceptación. Después de recibirla con éxito, analizará el FastCGI, luego ejecutará el script correspondiente, cerrará la solicitud después de procesarla y continuará esperando. para nuevas conexiones Este es el ciclo de vida del proceso de trabajo. Puede verse en el ciclo de vida del proceso de trabajo que un proceso de trabajo solo puede procesar una solicitud, y la siguiente solicitud se procesará solo después de que se procese una solicitud, lo que significa que es un modelo de bloqueo. Este modelo de Fpm simplifica enormemente la gestión de recursos de PHP, por lo que no es necesario considerar los conflictos de recursos causados por la concurrencia en el modo Fpm.
Nota : Los pits que se pueden encontrar en la situación de bloqueo, si la solicitud concurrente actual hace que Fpm exceda el número configurado de procesos secundarios de trabajador, causará bloqueo, la solicitud se ralentizará y la respuesta no será oportuna.
encuesta de trabajadores
Fpm puede monitorear múltiples puertos, cada puerto corresponde a una encuesta de trabajador y cada grupo corresponde a múltiples procesos de trabajo Estos procesos de trabajo que pertenecen a diferentes grupos todavía son administrados por el proceso maestro.
En php-fpm.conf, declare una encuesta de trabajador a través de [nombre del grupo], y cada encuesta se configura con su propia dirección de escucha, método de gestión de procesos, número de procesos de trabajo, etc.
[web1]
listen = 127.0.0.1:9000
[web2]
listen = 127.0.0.1:9001
Inicialización de Fpm
Elemento de configuración
[pool name] //pool 名称
user = nginx //Fpm的启动用户
group = nginx //Fpm的启动分组
listen = 127.0.0.1:9000 // 监听IP及端口
pm = dynamic // 进程模式，静态模式，动态模式，按需分配
pm.max_children = 5 // 最大worker进程数
pm.start_servers = 2 // 启动时初始化的worker进程数
pm.min_spare_servers = 1 // 最小空闲worker进程数
pm.max_spare_servers = 3 // 最大空闲worker进程数
pm.process_idle_timeout = 10s; // worker空闲时间
pm.max_requests = 500 // worker处理的最多请求数，超过这个值worker将被kill
Resumen de fpm
Fpm es un administrador de procesos del modo operativo PHP FastCGI, con un proceso maestro y un proceso de trabajo de la bifurcación. El proceso maestro gestiona el proceso de trabajo. En modo dinámico, si el proceso inactivo es menor que pm.min_spare_servers (el número mínimo de procesos de trabajo inactivos), el proceso inactivo aumenta y si el proceso inactivo es mayor que pm.max_spare_servers (el número máximo de procesos de trabajo inactivos) , el proceso redundante se mata y el número total de procesos no excede max_children. Fpm es bloqueante, fácil de administrar y asignar recursos, pero si una gran concurrencia hará que los datos estén ocupados y regresen a tiempo (bloqueo de espera), el proceso de espera bloqueado también se verá afectado por listen.backlog y el número de solicitudes en espera excede la configuración de listen.backlog Después del valor de, la parte excedente de la solicitud vuelve directamente a fallar; el
servidor web (nginx, etc.) escucha el puerto 80 (u otros puertos, el puerto http80 predeterminado) y reenvía la solicitud procesamiento y análisis al puerto correspondiente al protocolo FastCGI especificado en el archivo de configuración nginx (generalmente es el puerto 9000), el proceso de trabajo en Fpm escuchará para recibir los datos del puerto especificado para su procesamiento y devolverá el resultado a nginx después el procesamiento se completa, y nginx luego retroalimentará al solicitante.