Configuración de PHP-FPM: usamos pm static para un rendimiento máximo

Configuración de PHP-FPM: usamos pm static para un rendimiento máximo

La versión no editada del artículo fue publicada originalmente en haydenjames.io y se publica aquí con el permiso de su autor.

Voy a explicar brevemente cómo configurar PHP-FPM para maximizar el rendimiento, reducir la latencia y utilizar de manera más estable los recursos de CPU y memoria. Por defecto, la línea PM (gestor de procesos) en PHP-FPM está configurada como dynamic, y si no tienes suficiente memoria, es mejor establecer ondemand. Compararemos 2 opciones de gestión basadas en la documentación de php.net y veremos cómo se diferencian de mi favorito static pm para grandes volúmenes de tráfico:

pm = dynamic — el número de procesos hijos se ajusta dinámicamente en función de las siguientes directivas: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — los procesos se crean bajo demanda (a diferencia de la creación dinámica, donde pm.start_servers se inicia al arrancar el servicio).
pm = static — el número de procesos hijos es fijo y se especifica mediante el parámetro pm.max_children.

Vea los detalles en una lista completa de directivas globales en php-fpm.conf.

Las similitudes entre el gestor de procesos de PHP-FPM y el regulador de frecuencia de la CPU

Puede parecer fuera de lugar, pero voy a relacionarlo con el tema de la configuración de PHP-FPM. ¿Quién no ha experimentado el retraso de la CPU, ya sea en una laptop, máquina virtual o servidor dedicado? ¿Recuerdas el escalado de frecuencia del procesador? Estos parámetros disponibles para nix y Windows pueden mejorar el rendimiento y la velocidad de respuesta del sistema si cambias el parámetro del regulador de CPU de ondemand en performance*. Esta vez, comparemos las descripciones y veamos las similitudes:

Governor = ondemand — escalado dinámico de la frecuencia de la CPU en función de la carga actual. Acelera a la máxima frecuencia y luego la reduce cuando aumentan los períodos de inactividad.
Governor = conservative = escalado dinámico de la frecuencia según la carga actual. Aumenta y disminuye la frecuencia de manera más suave que ondemand.
Governor = performance — la frecuencia siempre es máxima.

Vea los detalles en una lista completa de parámetros del regulador de frecuencia de la CPU.

¿Ves la similitud? Quería mostrar esta comparación para convencerte de que lo mejor es usar pm static para PHP-FPM.

Para el regulador de la CPU, el parámetro performance ayuda a aumentar la rendimiento de manera segura, porque depende casi por completo del límite del procesador del servidor. Además de esto, claro, hay otros factores como la temperatura, la carga de la batería (en una laptop) y otros efectos secundarios del funcionamiento continuo del procesador al 100%. La configuración de rendimiento asegura el funcionamiento más rápido del procesador. Por ejemplo, lea acerca de el parámetro force_turbo en Raspberry Pi, con el cual el panel RPi utilizará el regulador performance, donde la mejora del rendimiento será más notable debido a la baja frecuencia de reloj de la CPU.

El uso de pm static para alcanzar el máximo rendimiento del servidor

El parámetro PHP-FPM pm static depende en gran medida de la memoria libre en el servidor. Si hay poca memoria, es mejor elegir ondemand o dynamic. Por otro lado, si se tiene memoria, se pueden evitar costos innecesarios del gestor de procesos PHP al establecer pm static a la capacidad máxima del servidor. En otras palabras, si se calculan bien todas las variables, hay que establecer pm.static a la máxima cantidad de procesos PHP-FPM que pueden ejecutarse, sin crear problemas de falta de memoria o caché. Pero no tan alto como para sobrecargar los procesadores y acumular un montón de operaciones PHP-FPM en espera de ejecución.

Configuración de PHP-FPM: usamos pm static para un rendimiento máximo

En la captura de pantalla anterior, el servidor está configurado con pm = static y pm.max_children = 100, lo que consume aproximadamente 10 GB de los 32 disponibles. Observe las columnas resaltadas, aquí está todo claro. En esta captura de pantalla había aproximadamente 200 usuarios activos (más de 60 segundos) en Google Analytics. A este nivel, alrededor del 70% de los procesos secundario de PHP-FPM aún están inactivos. Esto significa que PHP-FPM siempre está configurado para aprovechar al máximo los recursos del servidor, independientemente del tráfico actual. El proceso inactivo espera los picos de tráfico y responde de inmediato. No tiene que esperar a que pm cree procesos secundarios y luego los finalice cuando expire el período pm.process_idle_timeout. He establecido un valor muy alto para pm.max_requests, porque este es un servidor en funcionamiento sin fugas de memoria en PHP. Puede establecer pm.max_requests = 0 con static, si está completamente seguro de los scripts PHP actuales y futuros. Pero es mejor reiniciar los scripts con el tiempo. Establezca un gran número de solicitudes, ya que queremos evitar costos innecesarios de pm. Por ejemplo, al menos pm.max_requests = 1000 — dependiendo de la cantidad pm.max_children y el número de solicitudes por segundo.

En la captura de pantalla se muestra el comando Linux top, filtrada por u (usuario) y nombre de usuario PHP-FPM. Muestra solo los primeros 50 procesos o alrededor de eso (no los conté exactamente), pero, en esencia, top muestra las estadísticas principales que se colocan en la ventana del terminal. En este caso, ordenado por % de CPU (%CPU). Para ver todos los 100 procesos de PHP-FPM, ejecuta el comando:

top -bn1 | grep php-fpm

Cuándo usar pm ondemand y dynamic

Si usas pm dynamic, aparecen errores como los siguientes:

WARNING: [pool xxxx] parece ocupado (puedes necesitar aumentar pm.start_servers, o pm.min/max_spare_servers), creando 32 hijos, hay 4 inactivos, y 59 hijos en total

Intenta cambiar el parámetro, el error no desaparecerá, como se describe en este post en Serverfault. En este caso, el valor de pm.min era demasiado bajo, y dado que el tráfico web fluctúa significativamente y tiene picos altos y caídas profundas, es complicado ajustar adecuadamente pm dynamic. Normalmente se utiliza pm ondemand, como se aconseja en el mismo post. Pero esto es aún peor, ya que ondemand finaliza los procesos inactivos hasta cero, cuando apenas hay tráfico o no hay ninguno, y al final seguirás enfrentando costos debido a los cambios en el tráfico. A menos que, por supuesto, hayas establecido un tiempo de espera muy alto. En ese caso, es mejor usar pm.static + un número alto pm.max_requests.

PM dynamic y especialmente ondemand pueden ser útiles si tienes varios grupos de PHP-FPM. Por ejemplo, si alojas varias cuentas cPanel o varios sitios web en diferentes grupos. Tengo un servidor donde, digamos, hay más de 100 cuentas cPanel y aproximadamente 200 dominios, y pm.static o incluso dynamic no me salvaría. Aquí solo necesitas ondemand, ya que más de dos tercios de los sitios web reciben poco tráfico o ninguno, y con ondemand todos los procesos hijos se caerán, ¡lo que nos ahorrará mucha memoria! Afortunadamente, los desarrolladores de cPanel notaron esto y establecieron el valor predeterminado ondemand. Antes, cuando el valor predeterminado era dynamic, PHP-FPM no era apto para servidores compartidos con alta carga. Muchos utilizaban suPHP, porque pm dynamic consumía memoria incluso con grupos y cuentas cPanel inactivas PHP-FPM. Probablemente, con un buen tráfico no te alojarás en un servidor con un gran número de grupos PHP-FPM (alojamiento compartido).

Conclusión

Si usas PHP-FPM y tienes un tráfico serio, los administradores de procesos ondemand y dynamic para PHP-FPM limitarán el rendimiento debido a los costos inherentes. Examina tu sistema y ajusta los procesos de PHP-FPM de acuerdo con la capacidad máxima del servidor. Primero establece pm.max_children dependiendo del uso máximo de pm dynamic o ondemand, y luego aumente este valor hasta el nivel en el que la memoria y el procesador funcionen sin sobrecarga excesiva. Notará que pm static, dado que todo se almacena en la memoria, los picos de tráfico con el tiempo causarán menos picos en el procesador y los promedios de carga del servidor y del procesador se equilibrarán. El tamaño promedio del proceso PHP-FPM depende del servidor web y requiere configuración manual, por lo que los administradores de procesos más automatizados son dynamic y ondemand — más populares. Espero que el artículo haya sido útil.

UPD Se ha añadido un gráfico de referencia ab. Si los procesos PHP-FPM están en la memoria, el rendimiento aumenta gracias al consumo de memoria, donde permanecen a la espera. Encuentre la mejor opción para usted.

Configuración de PHP-FPM: usamos pm static para un rendimiento máximo

Fuente: habr.com

Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS 🔥 Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS | ProHoster