(Last Updated On: septiembre 19, 2018)

¿alguna vez has pasado horas afinando php-FPM, el estrés lo probó hasta que todo funciona sin problemas. ¿desplegar sus cambios en la producción y en unas pocas horas o días se bloquea de repente? requiriendo un reinicio manual, mientras mientras tanto tomando su sitio web completo sin conexión? sigue leyendo. PHP-FPM es muy difícil de sintonizar correctamente y hay tantas variables que hace que sea casi imposible para proporcionarle la configuración final. Sin embargo, ciertamente puedo guiarte en la dirección correcta para afinarlo para obtener el máximo rendimiento y fiabilidad. Problemas comunes para PHP-FPM que se estrella después de afinar

  • Has sintonizado y tensionado php-FPM probado en las páginas en caché, pero se olvidó de ver cómo se realiza en las páginas no almacenadas en caché
  • Usted no está simulando suficientes conexiones, lo que resulta en php-FPM corriendo fuera de PM. Niños y estrellarse
  • Has afinado php-FPM para usar mucho más RAM de lo que realmente tienes. Este es un problema muy común cuando se sintoniza en una página almacenada en caché, pero no se prueba en páginas no almacenadas en la caché. Recuerde, una página no cacheada necesita ejecutar una gran cantidad de PHP, requiriendo mucho más RAM que servir una página HTML en caché.

PHP-FPM Tuning

Ahora vamos a empezar, la configuración que necesitaría para cambiar vivirá en el siguiente archivo:

nano/etc/php/7.0/FPM/Pool.d/www.conf

Necesitará desplazarse hacia abajo y encontrar las siguientes líneas. Nota: no están todos juntos como se muestra a continuación.

PM = dinámico

PM. Max _children = 4

PM. start_servers = 2

PM. min _spare_servers = 1

PM. Max _spare_servers = 3

PM. Max _requests = 200

Éstos son los ajustes dominantes que dependerán pesadamente de cómo es confiable php-FPM será y mucho tráfico que puede manejar. Antes de comenzar a afinar para PHP-FPM, necesitará usar una herramienta de prueba de esfuerzo del servidor. Yo personalmente utilizo una herramienta SEO llamada ScreamingFrog donde puedo configurar la velocidad de rastreo muy alta, que simulará el tráfico en páginas aleatorias. Sin embargo, esta es una herramienta pagada. Si no tiene acceso a esto, puede utilizar algo como la herramienta de prueba de tensión de Apache que se puede instalar usando el siguiente comando

sudo apt-get install apache2-utils

Para ejecutar una prueba de esfuerzo se usaría la siguiente línea de comandos

AB-c 100-t 60-r http://example.com/

-c 100 significa 100 peticiones por segundo y-t 60 significa por 60 segundos. Se recomienda encarecidamente que ejecute este comando desde un servidor diferente al que está probando. Aquí podrá ver cuántas solicitudes puede manejar su servidor, cuánto tiempo tardó en completar las solicitudes y si php-FPM se bloquea junto con la cantidad de memoria que está usando bajo carga usando ' htop '. Aquí es donde usted ajustaría la configuración hasta que encuentre el rendimiento óptimo. El elemento clave aquí será ' PM. Max _children '. Establecer este demasiado alto y el servidor se bloqueará, establecer esta demasiado bajo y de nuevo su servidor se bloqueará. Esto depende en gran medida de la cantidad de RAM de su servidor, la cantidad de CPU y la aplicación que está ejecutando es decir, WordPress, Magento etc. Los números altos normalmente se realizan mejor para los servidores de CPU de varios núcleos que sirven a las páginas en caché. Sin embargo, es probable que se estrelle php-FPM si se obtiene un aumento de la solicitud en las páginas no cacheadas. Esto es lo que hace que esto sea difícil de hacer bien. El segundo más importante es ' PM. Max _requests ', después de días de pruebas siempre he encontrado establecer este a 0 (ilimitado) proporciona los mejores resultados cuando se trata de alta concurrencia. Aprecio que algunos de ustedes pueden desear cifras reales, aquí hay uno que hice en un servidor de 8 núcleos con 16 GB de RAM, ejecutando WordPress y la página completa en memoria caché en Redis.

PM = dinámico

PM. Max _children = 12

PM. start_servers = 6

PM. min _spare_servers = 4

PM. Max _spare_servers = 8

PM. Max _requests = 0

  La configuración anterior me permitió probar hasta 1.400 solicitudes por segundo antes de maximizar el ancho de banda de los servidores en 2GB/s. Consejo: cuando se prueba la tensión alta concurrencia, asegúrese de que no tiene otros cuellos de botella, como el servidor que se queda sin conexiones TCP/IP, o Nginx mantener las conexiones abiertas durante demasiado tiempo! Este es un problema común con la alta concurrencia donde se puede pasar horas tratando de obtener su configuración correcta, sin darse cuenta de que PHP-FPM no es su cuello de botella.