Afinando la ejecución de PHP

WordPress, Magento, Nextcloud… El mundo está lleno de aplicaciones escritas en PHP. Desde que el bueno de Rasmus Lerdorf lo creara (en una forma casi irreconocible hoy), han pasado ya 30 años. Por su sencillez de uso y diseño perfecto para generar páginas web, se ha impuesto como una de las piezas básicas de muchos de los servicios que usamos.

En nuestro mundo de albergar aplicaciones escritas en PHP, nuestros principales problemas son solamente dos: cómo ejecutar PHP rápido y seguro.

En cuanto a la seguridad de PHP, podemos escribir mucho y no solamente sobre la seguridad del lenguaje en sí, sino también sobre sus muchas ramificaciones. Por ejemplo: la sencillez de uso de PHP ha llevado a que exista mucho código con un diseño de seguridad insuficiente.

Pero hoy vamos a hablar de «ejecutar PHP rápido». PHP se puede ejecutar de varias maneras, y las comunes (y que tradicionalmente hemos implementado en Tecnocrática) son:

• Módulo de Apache DSO
• FastCGI
• FPM

Podríamos decir que ejecutar PHP como módulo de Apache es la forma más clásica. Tiene la ventaja de que es sencilla de implementar y da un rendimiento razonable. Pero también tiene inconvenientes que hacen que no sea lo más apropiado para entornos como el de Tecnocrática:

• Acopla rígidamente Apache y PHP
• Los ficheros de la web han de ser legibles por el usuario del servidor web. En alojamientos compartidos, esto es un grave problema de seguridad.
• No permite afinar la ejecución de cada web por separado.

FastCGI, que ha sido el principal ejecutor de PHP durante mucho tiempo en nuestra plataforma, resuelve varios de estos inconvenientes.

Con FastCGI, los procesos de PHP son separados del proceso del servidor web, por lo que permite ejecutar cada web con procesos diferentes. Esto, a su vez, hace que sea posible que cada web pueda ejecutar la versión de PHP y con el usuario que convengan al caso (para lo cual utiliza suEXEC). Ambas cosas, necesarias en entornos de hosting.

FPM es una alternativa que mejora FastCGI. Su diseño es algo así como un FastCGI con un gestor de procesos. Mejora un poco más aún la separación entre webs, permitiendo que cada una tenga su propia raíz de ficheros, usuario, etc. Y sobre todo, es rápido. Especialmente, en webs con mucho tráfico o que sufren problemas de rendimiento debido a la visita de robots.

Hace algún tiempo que hemos incorporado FPM en la plataforma de Neodigit. La experiencia frente a FastCGI es muy buena en rendimiento en la práctica totalidad de las webs del mundo real. Igualmente importante, no se han generado problemas nuevos.

Cada modo de ejecución de los revisados añade nuevos controles que es necesario ajustar adecuadamente para evitar incidencias y obtener el máximo rendimiento.

Hablando de rendimiento…

Esta es una prueba rápida con siege sobre la web personal de un servidor. Sencillamente desde mi ordenador (conectado por cable de forma bastante directa al centro de datos donde vive dicha web):

siege --time=33s https://alfredo.sola.es

Y los resultados son como sigue (las negritas son para resaltar algunos parámetros especialmente interesantes).

FastCGI

Transactions: 17305 hits
Availability: 100.00 %
Elapsed time: 33.52 secs
Data transferred: 1085.52 MB
Response time: 0.05 secs
Transaction rate: 516.26 trans/sec
Throughput: 32.38 MB/sec
Concurrency: 24.06
Successful transactions: 17309
Failed transactions: 0
Longest transaction: 4.97
Shortest transaction: 0.00

FPM

Transactions: 23255 hits
Availability: 100.00 %
Elapsed time: 33.30 secs
Data transferred: 1455.78 MB
Response time: 0.03 secs
Transaction rate: 698.35 trans/sec
Throughput: 43.72 MB/sec
Concurrency: 24.16
Successful transactions: 23256
Failed transactions: 0
Longest transaction: 0.69
Shortest transaction: 0.00

Conclusiones

Como se puede ver, es fácil encontrar un caso en que una web en PHP es capaz de atender más peticiones y más deprisa en el mismo tiempo con FPM que con FastCGI. Junto con la ausencia de problemas nuevos, esto hace que cambiar de FastCGI a FPM sea aconsejable en el sentido más amplio.