Utilizar la página de estado de PHP-FPM para el análisis del rendimiento

Lo que muestra la página de estado sobre el grupo

La página de estado de PHP-FPM muestra cómo un determinado piscina Solicitudes PHP procesadas: entre otras cosas, cuántos procesos están activos o libres y si hay solicitudes en espera. Es necesario que la aplicación esté realmente gestionada por PHP-FPM. La versión de PHP que se muestra en la línea de comandos por sí sola no indica ni esto ni la versión del servicio FPM correspondiente.

Por lo tanto, comprueba primero la versión de FPM utilizada y el grupo al que el servidor web reenvía la aplicación. Esto incluye el socket Unix o el listener TCP utilizado, así como el enrutamiento en el host virtual correspondiente. Esta asignación es importante para que una consulta de estado posterior no se refiera por error a otro grupo.

Si un servidor gestiona varios grupos, la información mostrada se refiere únicamente al grupo consultado y no se aplica automáticamente a todas las aplicaciones PHP. En el alojamiento compartido, es posible que no dispongas de los permisos necesarios para configurar el grupo o el servidor web. En ese caso, dependerás de que el proveedor facilite la página de estado o indicadores similares de forma protegida.

Una consulta es, en primer lugar, una Instantánea: Entre dos consultas pueden aparecer y desaparecer colas cortas. Otros valores contabilizan los eventos desde el inicio del FPM; al reiniciar el sistema, se reinician. Por lo tanto, para obtener un historial significativo, guarda la hora de consulta y la identidad del grupo junto con los valores.

Esta página no explica la totalidad del tiempo de espera en el navegador. La red, el servidor web, la base de datos y los servicios externos también pueden influir en el tiempo de respuesta. Por lo tanto, constituye un punto de partida para el diagnóstico del grupo de PHP-FPM, pero no una prueba de rendimiento completa del sitio web.

Entender los «workers» y los gestores de procesos

El gestor de procesos determina cómo el grupo de recursos asigna sus trabajadores. En el caso de static su número se mantiene constante. dynamic ajusta el número según las necesidades, dentro de los límites configurados; ondemand inicia procesos cuando es necesario. Por lo tanto, la capacidad libre que esperas depende también del modo de funcionamiento seleccionado.

Un proceso activo está tramitando una solicitud en este momento; un proceso libre está disponible para trabajar. El hecho de que haya muchos trabajadores activos no supone automáticamente un error: un grupo de trabajadores con mucha carga de trabajo puede tramitar las solicitudes con rapidez. La observación cobra mayor relevancia cuando, al mismo tiempo, hay solicitudes en espera, los tiempos de respuesta aumentan y apenas hay procesos libres disponibles.

El hecho de que una reserva esté vacía durante un breve periodo de tiempo no es, por sí solo, prueba de que exista un cuello de botella permanente. Compara las consultas repetidas con la configuración Límite del proceso y los momentos en los que los usuarios perciben realmente retrasos. Así podrás distinguir mejor un pico de carga breve de una sobrecarga recurrente.

Un mayor número de trabajadores puede procesar más solicitudes en paralelo, pero requiere más memoria y puede suponer una mayor carga para las bases de datos o los servicios externos. Si hay muchos procesos a la espera de la misma dependencia lenta, aumentar el límite no elimina la causa. Por lo tanto, comprueba los recursos y la duración de las solicitudes antes de pm.max_children cambiar.

Para definir las competencias dentro de la pila de alojamiento, resulta útil comparar NGINX Unit y PHP-FPM. Complementa la perspectiva arquitectónica; debes seguir comprobando los valores de estado concretos y la configuración del gestor de procesos en el grupo de FPM que se utilice realmente.

Proteger el acceso a Status y FastCGI

La información de estado puede revelar datos confidenciales sobre las solicitudes y los recursos. En concreto, los detalles del proceso pueden contener URI de solicitud que permitan deducir qué funciones se han invocado o qué parámetros se han enviado. Por lo tanto, considera esta página como un acceso de diagnóstico y no como un panel de estado público.

Limita el Acceso HTTP a solicitudes internas o a direcciones IP de clientes expresamente identificadas. Comprueba qué dirección ve realmente el servidor web como cliente cuando hay un proxy intercalado. La protección debe aplicarse al enrutamiento de la página de estado y debería verificarse antes de su publicación.

Asegúrate, independientemente de eso, de que el Acceso a FastCGI por sí mismo. En el caso de un socket de Unix, son relevantes el propietario y los permisos; en el caso de TCP, hay que comprobar la conexión de red y los clientes autorizados. Un bloqueo en el servidor web no protege un puerto FastCGI al que se pueda acceder por separado desde una red poco fiable.

El proyecto PHP ha documentado, con el número CVE-2026-6735, una vulnerabilidad XSS en la salida de estado de FPM. Las versiones corregidas incluyen PHP 8.4.21 y 8.5.6. Para otras ramas de versiones y paquetes de distribución, comprueba el estado de seguridad correspondiente o los parches retroportados, en lugar de dar por hecho que estás protegido basándote únicamente en el número de versión que se muestra.

Una actualización no sustituye a la restricción de acceso: incluso una página de estado corregida puede seguir revelando detalles operativos. Mantén tanto el acceso HTTP como el listener limitados al grupo de usuarios previsto y ten en cuenta estas dos capas de protección al realizar modificaciones posteriores en el enrutamiento.

Publicar la página de estado de forma protegida

En primer lugar, averigua qué grupo FPM procesa la aplicación en cuestión y a través de qué socket o dirección TCP accede a él el servidor web. Si hay varios grupos, la consulta de estado se asigna al grupo al que se reenvía. La versión de PHP de la línea de comandos por sí sola no indica qué servicio FPM es el responsable de la aplicación.

En el archivo de configuración del grupo correspondiente, el siguiente fragmento activa el Ruta de estado. No se trata de un archivo PHP que tengas que crear en el directorio de documentos. El fragmento es una propuesta de configuración y requiere que tengas permiso para editar la configuración del pool.

pm.status_path = /fpm-status

Configura en el servidor web una ruta adecuada que reenvíe las solicitudes a esta ruta directamente a través de FastCGI al grupo determinado. El enrutamiento habitual de la aplicación no debe interceptar la solicitud. Limita el acceso HTTP a las solicitudes internas o a direcciones IP de clientes conocidos y protege el socket de FastCGI independientemente de ello mediante permisos o restricciones de red y clientes autorizados.

Antes de la implementación autorizada, comprueba tanto la configuración del servidor web como la de FPM mediante los procedimientos de comprobación previstos en tu entorno. Asegúrate de que estás modificando el servicio y el grupo correctos, y de que la restricción de acceso también se aplica a la ruta de estado. El mero hecho de establecer una ruta no garantiza que el contenido sea accesible a través de HTTP.

En un entorno ya configurado y protegido localmente, el siguiente comando de terminal lee la salida JSON. Requiere que se pueda acceder a un host virtual HTTP local adecuado en la dirección indicada. De lo contrario, deberás adaptar la dirección y el enrutamiento del host, así como TLS si fuera necesario, a tu entorno; la consulta no modifica ninguna configuración.

curl --fail --silent --show-error 'http://127.0.0.1/fpm-status?json'

En la respuesta, comprueba especialmente el nombre del grupo. Un mensaje de error o una salida inesperada de la aplicación pueden indicar un enrutamiento incorrecto; además, un bloqueo de acceso también puede impedir la recuperación de datos. A continuación, comprueba la configuración del servidor web correspondiente y los registros, en lugar de desactivar la protección de forma precipitada.

Cómo interpretar y calcular correctamente los indicadores clave

Los valores de estado describen distintos periodos de tiempo: algunos muestran el estado en el momento de la consulta, otros contabilizan eventos o registran un valor máximo desde el inicio. Para un diagnóstico, esta distinción es más importante que un único valor anómalo. La siguiente tabla clasifica los datos fundamentales.

Para un Velocidad de conexión¿Restas dos valores de accepted conn suma uno a otro y divide la diferencia entre el tiempo transcurrido. Ejemplo de cálculo hipotético, sin medición: si el contador pasa de 12 000 a 12 600 en 60 segundos, se obtiene una media de diez conexiones estimadas por segundo. De ello no se pueden deducir directamente ni las visitas a la página ni la latencia de la aplicación.

Guarda la hora y la identidad del grupo en cada punto de medición. Tras un reinicio del FPM, los valores de estado se restablecen; por lo tanto, una diferencia que traspase este punto de ruptura no constituye una tasa válida. Detecta si el contador ha bajado o si ha cambiado la hora de inicio y vuelve a iniciar el cálculo para el nuevo periodo.

En max children reached el gestor de procesos es fundamental: la configuración de ejemplo de PHP 8.4.21 describe el contador para «dynamic» y «ondemand». En el caso de «static», no debes interpretar un valor cero como indicio de capacidad libre. Para slow requests El umbral y el slowlog deben configurarse adecuadamente; el umbral determina qué solicitudes largas se registran.

Comparar formatos de salida y detalles del proceso

La versión breve es ideal para obtener una visión general de toda la piscina. A la hora de elegir el formato, es fundamental tener en cuenta si quieres leer los valores manualmente o procesarlos periódicamente mediante un sistema de monitorización. El parámetro full amplía la salida con detalles del proceso; no es un formato de intercambio independiente.

El manual de PHP también incluye documentación sobre XML y HTML. En las consultas automatizadas, comprueba la versión de FPM realmente instalada y su salida antes de basarte en campos concretos o en detalles del proceso. En particular, deberías tener en cuenta la combinación de OpenMetrics y full comprobarlo en la propia versión, en lugar de dar por sentado de forma generalizada los datos de procesos individuales.

El Duración de la solicitud En la versión «Full», el valor se expresa en microsegundos. En el caso de un proceso activo, indica la duración de la solicitud que se está procesando en ese momento; en el caso de un proceso inactivo, se refiere a la última solicitud procesada. Por lo tanto, un valor elevado en un worker libre no significa que este siga ocupado con la solicitud.

Los campos last request cpu y last request memory En el caso de los procesos activos, se muestran como cero, ya que su evaluación no se realiza hasta que finaliza la consulta. Por lo tanto, estos valores cero no indican un consumo de CPU o memoria ausente. Las consultas repetidas pueden indicar si un proceso permanece activo durante más tiempo; sin embargo, no sustituyen a un seguimiento completo de la aplicación.

Analizar las colas y las solicitudes lentas

Si el cola Si esto se repite cuando hay muchos procesos activos y pocos libres, una hipótesis de trabajo plausible es que el grupo de recursos esté saturado. Una sola consulta no basta para ello: compara varios momentos y fíjate si, al mismo tiempo, aumentan los tiempos de respuesta a las consultas. El valor máximo de la cola, por sí solo, no indica si aún hay solicitudes en espera.

Compara ese periodo con los registros de FPM, la carga de la CPU y la memoria disponible. Ten en cuenta también la base de datos, la caché y los servicios externos: si PHP está esperando una dependencia lenta, los trabajadores permanecen ocupados, aunque un mayor rendimiento de la CPU por sí solo no tiene por qué resolver el problema. La página de estado muestra la ocupación, pero no indica de forma fiable cuál es su causa.

Consulta repetidamente la salida completa protegida durante una fase que llame la atención. Una duración prolongada de la solicitud en el mismo proceso activo puede indicar que un trabajador lleva mucho tiempo ocupado; comprueba el estado del proceso, ya que, en el caso de un proceso inactivo, la duración se refiere a su última solicitud. El PID, el URI y el script ayudan a la identificación, pero no proporcionan un rastreo completo.

Precisamente en el caso de un controlador frontal, un mismo nombre de script puede abarcar muchas funciones de aplicación diferentes. Por lo tanto, complementa esta observación con el seguimiento de la aplicación y una configuración adecuada de Slowlog. Su umbral determina qué solicitudes largas se registran; el hecho de que no haya ninguna entrada no significa que todas las solicitudes fueran rápidas. En el artículo sobre el Análisis del registro de operaciones lentas de PHP-FPM.

Para realizar la comparación, anota el intervalo de tiempo y el grupo afectado. De este modo, podrás comprobar, por ejemplo, si una consulta lenta a la base de datos coincide temporalmente con los trabajadores ocupados o si la cola ya se estaba acumulando antes. Una correlación limita la búsqueda, pero aún no sustituye al análisis de la solicitud concreta.

Supervisión y fallos de la página de estado

En el caso de picos de carga recurrentes, las consultas periódicas y protegidas son más significativas que las comprobaciones puntuales ocasionales. JSON es adecuado para el procesamiento automatizado; OpenMetrics es una alternativa si la versión de PHP instalada y el cliente de monitorización son compatibles. Guarda, para cada punto de medición, la hora y la identidad del grupo, para no comparar por error grupos diferentes.

Trata consultas pendientes como eventos independientes y no como valores nulos. Una brecha puede deberse a la red, a la protección de acceso o al servicio de estado; por sí sola, no indica ni un grupo vacío ni un fallo de la aplicación. Por lo tanto, guarda también los errores y los tiempos de espera de la consulta, para que la brecha siga siendo visible en el análisis posterior.

Ten en cuenta, además, los reinicios de los contadores acumulados tras un reinicio del FPM. Una diferencia negativa entre dos valores no equivale a una tasa de conexión negativa; vuelve a iniciar el cálculo tras el reinicio y ten en cuenta el intervalo interrumpido. La hora de inicio y la asignación al grupo también ayudan a contextualizar dicha interrupción en la evolución.

Si la consulta de estado se ejecuta en el mismo grupo que la aplicación, puede esperar por sí misma en caso de que se agoten los trabajadores. Para esta situación, ofrece pm.status_listen un listener FastCGI independiente con un grupo interno que funciona de forma autónoma. Permite realizar diagnósticos de estado mientras el grupo principal está ocupado; sin embargo, no aumenta su capacidad de procesamiento.

El listener adicional requiere una ruta de enrutamiento del servidor web protegida y asignada expresamente. Asegúrate también de que su acceso a FastCGI sea seguro y, tras realizar un cambio autorizado, comprueba si la consulta proporciona realmente el estado del grupo deseado. De este modo, el diagnóstico permanece separado de la ruta normal de la aplicación, sin que los datos de estado sean de acceso público.

Analizar los resultados y seleccionar las medidas

Un ping de FPM y la página de estado responden a preguntas diferentes. El ping muestra si FPM responde a la solicitud correspondiente; no proporciona información equivalente sobre los trabajadores libres o las solicitudes en espera. Por lo tanto, un ping satisfactorio por sí solo no significa que no haya motivos de preocupación respecto a la carga del grupo de aplicaciones.

Si las cifras del proceso no coinciden con los registros u otras observaciones, comprueba en primer lugar la asignación del pool, el momento de la recuperación y la posibilidad de reiniciar el sistema. A continuación, compara los valores con otros datos de proceso y de funcionamiento disponibles. Trata la discrepancia, en un primer momento, como un hallazgo pendiente, en lugar de deducir inmediatamente una causa o un cambio de configuración necesario.

Si las consultas «Full» repetidas y las entradas del «Slowlog» muestran los mismos patrones de peticiones prolongadas, analiza primero las rutas de la aplicación afectadas. Por el contrario, si el retraso se produce en una base de datos o en un servicio externo, su análisis puede ser más eficaz que modificar el número de trabajadores. Lo fundamental es que la medida aborde la causa observada, y no solo un síntoma aislado.

Una adaptación de pm.max_children Es una opción a tener en cuenta cuando se demuestre que el pool está funcionando al límite de su capacidad y que la CPU, la memoria y los servicios posteriores puedan soportar un mayor nivel de paralelismo. Un mayor número de trabajadores requiere más recursos y puede aumentar la carga sobre dichos servicios. Por lo tanto, no existe una cifra válida para todos los casos; el modo de funcionamiento del gestor de procesos debe tenerse en cuenta en la evaluación.

Tras aplicar un cambio que se haya autorizado, vuelve a comparar ese mismo grupo de servidores en condiciones de carga lo más similares posible: la cola, los tiempos de respuesta, los errores y el consumo de recursos van de la mano. Anota también si una medida no aporta ninguna mejora o si aumenta la carga sobre una dependencia. Solo así Comparación «antes y después» permite tomar una decisión fundamentada sobre cómo proceder a partir de ahora.