Una versión no editada del artículo se publicó originalmente en haydenjames.io y se publica aquí con el permiso de su autor .
En pocas palabras, hablaré sobre la mejor manera de configurar PHP-FPM para aumentar el rendimiento, reducir la latencia y un uso más estable de los recursos del procesador y la memoria. Por defecto, la cadena PM (administrador de procesos) en PHP-FPM es dinámica , y si no tiene suficiente memoria, es mejor instalar ondemand . Comparemos 2 opciones de control basadas en la documentación de php.net y veamos cómo mi pm estático favorito difiere de ellas para una gran cantidad de tráfico:
pm = dinámico : el número de procesos secundarios se configura dinámicamente según las siguientes directivas: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers .
pm = ondemand : los procesos se crean a pedido (a diferencia de la creación dinámica, cuando pm.start_servers se inician cuando se inicia el servicio).
pm = static : el número de procesos secundarios es fijo y especificado por el parámetro pm.max_children .
Consulte la lista completa de directivas globales php-fpm.conf para obtener más detalles .
Las similitudes del administrador de procesos PHP-FPM con el controlador de frecuencia del procesador
Puede parecer fuera de tema, pero voy a relacionar esto con el tema de configuración de PHP-FPM. Quien al menos una vez no desaceleró el procesador: en una computadora portátil, una máquina virtual o un servidor dedicado. ¿Recuerdas la escala de la frecuencia del procesador? Estas opciones, disponibles para nix y Windows, pueden mejorar el rendimiento y la capacidad de respuesta del sistema al cambiar la configuración del controlador del procesador de ondemand a performance *. Esta vez, comparemos las descripciones y veamos las similitudes:
Governor = ondemand : escala dinámica de la frecuencia del procesador en función de la carga actual. Cambia bruscamente a la frecuencia máxima y luego la reduce cuando aumentan los períodos de inactividad.
Gobernador = conservador = escala de frecuencia dinámica dependiendo de la carga actual. Aumenta y disminuye la frecuencia más suave que ondemand.
Gobernador = rendimiento : la frecuencia siempre es máxima.
Consulte la lista completa de parámetros del controlador de frecuencia del procesador para obtener más detalles.
¿Ves el parecido? Quería mostrar esta comparación para convencerlo de que es mejor usar pm static para PHP-FPM.
Para un controlador de procesador, el parámetro de rendimiento ayuda a aumentar el rendimiento de forma segura porque depende casi por completo del límite del procesador del servidor. Además de esto, por supuesto, también hay factores como la temperatura, la carga de la batería (en una computadora portátil) y otros efectos secundarios del funcionamiento constante del procesador al 100%. El ajuste de rendimiento proporciona el rendimiento más rápido del procesador. Lea, por ejemplo, sobre el parámetro force_turbo en la Raspberry Pi , con el cual el panel RPi usará el regulador de rendimiento , donde la mejora del rendimiento será más notable debido a la baja velocidad de reloj de la CPU.
Usando pm static para maximizar el rendimiento del servidor
El parámetro estático PHP-FPM pm depende en gran medida de la memoria libre en el servidor. Si la memoria es baja, es mejor elegir ondemand o dinámico . Por otro lado, si tiene memoria, puede evitar la sobrecarga del administrador de procesos PHP estableciendo pm static en la capacidad máxima del servidor. En otras palabras, si todo está bien calculado, debe establecer pm.static en la cantidad máxima de procesos PHP-FPM que se pueden ejecutar sin crear problemas con memoria o caché insuficientes. Pero no tan alto como para sobrecargar los procesadores y acumular un montón de operaciones PHP-FPM en espera de ejecución .
En la captura de pantalla anterior, el servidor tiene instalado pm = static y pm.max_children = 100 , y esto toma alrededor de 10 GB de los 32 disponibles. Preste atención a las columnas resaltadas, todo está claro aquí. En esta captura de pantalla, había aproximadamente 200 usuarios activos (más de 60 segundos) en Google Analytics. En este nivel, aproximadamente el 70% de los procesos secundarios PHP-FPM todavía están inactivos. Esto significa que PHP-FPM siempre se establece en la cantidad máxima de recursos del servidor, independientemente del tráfico actual. Un proceso inactivo espera los picos de tráfico y responde instantáneamente. No tiene que esperar a pm para crear procesos secundarios y luego finalizarlos cuando expire el período pm.process_idle_timeout . Establecí un valor muy alto para pm.max_requests , porque es un servidor que funciona sin pérdidas de memoria en PHP. Puede configurar pm.max_requests = 0 con static si tiene plena confianza en los scripts PHP existentes y futuros. Pero es mejor reiniciar los scripts con el tiempo. Instale una gran cantidad de consultas, porque queremos evitar la sobrecarga innecesaria de pm. Por ejemplo, al menos pm.max_requests = 1000 , según el número de pm.max_children y el número de solicitudes por segundo.
La captura de pantalla muestra el comando superior de Linux , filtrado por u (usuario) y nombre de usuario PHP-FPM. Solo se muestran los primeros 50 procesos más o menos (no conté exactamente), pero, de hecho, top muestra las estadísticas superiores que se colocan en la ventana de terminal. En este caso, ordenado por% CPU (% CPU). Para ver los 100 procesos PHP-FPM, ejecute el comando:
top -bn1 | grep php-fpm
Cuándo usar pm ondemand y dinámico
Si usa pm dynamic , obtendrá errores similares:
WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children
Intente cambiar el parámetro, el error no irá a ningún lado, como se describe en esta publicación en Serverfault . En este caso, el valor de pm.min era demasiado pequeño, y dado que el tráfico web cambia mucho y tiene picos altos y caídas profundas, es difícil configurar adecuadamente pm dynamic . Esto generalmente usa pm ondemand , como se recomienda en la misma publicación . Pero esto es aún peor, porque ondemand finaliza los procesos inactivos a cero cuando hay poco o nada de tráfico y, como resultado, aún sufrirá costos cuando el tráfico cambie. A menos, por supuesto, que haya establecido un gran tiempo de espera. Y luego es mejor usar pm.static + una gran cantidad de pm.max_requests .
PM dinámico y especialmente ondemand pueden ser útiles si tiene múltiples grupos PHP-FPM. Por ejemplo, aloja múltiples cuentas de cPanel o múltiples sitios web en diferentes grupos. Tengo un servidor donde, por ejemplo, más de 100 cuentas de cpanel y alrededor de 200 dominios, y pm.static o incluso dinámico no me salvarían. Aquí solo se necesita ondemand , porque más de dos tercios de los sitios web reciben poco o nada de tráfico, y con ondemand todos los procesos secundarios se caerán, lo que nos ahorrará mucha memoria. Afortunadamente, los desarrolladores de cPanel se dieron cuenta de esto y establecieron el valor predeterminado en ondemand . Anteriormente, cuando el valor predeterminado era dinámico , PHP-FPM no era adecuado para servidores compartidos ocupados. Muchos usaron suPHP porque pm dynamic consumió memoria incluso con grupos inactivos y cuentas cPanel PHP-FPM. Lo más probable es que, con un buen tráfico, no se aloje en un servidor con una gran cantidad de grupos PHP-FPM (alojamiento compartido).
Conclusión
Si usa PHP-FPM y tiene mucho tráfico, los administradores de procesos dinámicos y bajo demanda para PHP-FPM limitarán el ancho de banda debido a sus costos inherentes. Examine su sistema y configure sus procesos PHP-FPM para que coincidan con su capacidad máxima de servidor. Primero configure pm.max_children dependiendo del uso máximo de pm dynamic o ondemand , y luego aumente este valor al nivel donde la memoria y el procesador funcionarán sin una sobrecarga excesiva. Notará que con pm static , ya que todo está almacenado en la memoria, los picos de tráfico con el tiempo causarán menos picos para el procesador, y los valores promedio de carga del servidor y del procesador se igualarán. El tamaño promedio del proceso PHP-FPM depende del servidor web y requiere una configuración manual, por lo que los administradores de procesos más automatizados, dinámicos y bajo demanda , son más populares. Espero que el artículo haya sido útil.
UPD Diagrama de referencia agregado ab . Si los procesos PHP-FPM están en la memoria, el rendimiento mejora al consumir la memoria donde se sientan y esperan. Encuentra la mejor opción para ti.
