Pruebas de rendimiento de la CPU del servidor para PHP: pruebas con cargas de trabajo reales de alojamiento web

Qué debe responder una prueba de rendimiento de PHP

Una prueba de rendimiento de la CPU con PHP puede mostrar, en primer lugar, cuánto tiempo tarda un sistema en realizar una tarea de cálculo determinada. Esto resulta especialmente útil cuando una sola solicitud dedica mucho tiempo a los cálculos de PHP. Un valor más alto Rendimiento de un solo núcleo puede acortar el tiempo de procesamiento de este tipo de tareas; sin embargo, a partir de un único valor de CPU no se puede deducir el tiempo de respuesta de toda una página web.

Una segunda cuestión se refiere al comportamiento de la aplicación ante accesos simultáneos: ¿cuántas respuestas correctas proporciona por segundo y cuánto tiempo tienen que esperar los usuarios? Para ello se necesita un Comparativa de alojamiento web a través de HTTP. Recoge el recorrido a través de los servidores web y PHP, así como, en su caso, la base de datos, la caché y la red. Precisamente esta combinación lo hace muy realista, aunque impide extraer una conclusión aislada sobre la CPU.

La tercera cuestión es la del cuello de botella. Si, por ejemplo, una solicitud está a la espera de una consulta a la base de datos, una operación de cálculo más rápida no dice mucho sobre su tiempo total. La caché también altera el resultado: si una página ya se ha servido por completo antes de que se ejecute PHP, la llamada no mide la ejecución de la aplicación dinámica.

Además, bajo una carga paralela, el grupo de procesos PHP-FPM puede limitar el número de solicitudes que se procesan simultáneamente. Su página de estado ofrece, entre otras cosas, información sobre los procesos en ejecución y las solicitudes en cola. Por lo tanto, una cola cada vez más larga es motivo para realizar un diagnóstico, pero no una prueba directa de que la CPU sea demasiado lenta.

A la hora de elegir un servicio de alojamiento, resulta útil analizar estas cuestiones por separado: primero, la unidad de trabajo comparable; después, el funcionamiento con cargas bajas y altas; y, por último, los recursos que limitan el resultado. El artículo sobre Hardware para alojamiento web de alto rendimiento.

Diferenciar entre puntuaciones de CPU y pruebas de aplicaciones

A Microbancada de pruebas repite una tarea pequeña y bien definida. Con PHPBench, por ejemplo, se puede analizar una función de procesamiento de datos en condiciones específicas. El resultado ayuda a comparar dicha función y su entorno de ejecución; no describe automáticamente una consulta completa ni el rendimiento de un CMS o una tienda online.

Una prueba de aplicación HTTP responde a otra pregunta: ¿cómo reacciona la aplicación elegida a través de la pila web que se utiliza realmente? Tiene en cuenta, por ejemplo, PHP-FPM, la base de datos y las cachés, en la medida en que intervengan en la llamada sometida a prueba. Por ello, resulta adecuado para evaluar una oferta de alojamiento, pero no puede demostrar por sí solo qué componente es el responsable de una diferencia.

SPEC CPU complementa estas pruebas con cargas de trabajo estandarizadas que requieren un gran esfuerzo computacional. SPEC CPU 2026 incluye conjuntos de pruebas de números enteros y de coma flotante, así como resultados de «Speed» y «Rate». «Speed» se refiere al tiempo necesario para realizar las tareas, mientras que «Rate» se refiere al rendimiento. Un valor de «Speed» no es automáticamente un valor exclusivo de un solo núcleo: SPEC señala la existencia de paralelismo adicional en las pruebas de «Speed» de números enteros de la suite 2026.

Para que una comparación SPEC sea fiable, la suite, la métrica y el tipo de resultado deben base o pico coinciden. Asimismo, lo que cuenta es el sistema probado en su totalidad: además del procesador, la memoria, el compilador y la configuración, entre otros factores, influyen en el resultado. Por lo tanto, los valores publicados no son una característica aislada del modelo de CPU y no sustituyen a una prueba de PHP.

SPEC CPU 2017 y CPU 2026 utilizan conjuntos de pruebas diferentes; sus cifras no se ajustan a la misma escala. Por lo tanto, a la hora de realizar una preselección, conviene comparar el informe completo de resultados en lugar de una clasificación resumida. Solo una prueba de rendimiento adecuada permitirá determinar si un candidato es adecuado para la aplicación concreta.

Establecer condiciones de prueba comparables

Una comparación justa comienza con la misma versión de la aplicación y un conjunto de datos comparable. La ruta elegida y la respuesta esperada también deben coincidir: una página de producto con muchos accesos a la base de datos responde a una pregunta diferente a la de una simple función de API. Por lo tanto, no te limites a comprobar si llega una respuesta, sino también si su contenido se ajusta a la tarea prevista.

Anota la versión de PHP y las extensiones, así como el servidor web, la configuración de PHP-FPM y la base de datos. La ruta de red entre el generador de carga y la aplicación también debe figurar en el informe. Las diferentes rutas o ubicaciones de la base de datos pueden alterar el tiempo de respuesta medido, incluso si la ejecución de PHP fuera igual de rápida en ambos sistemas.

Es especialmente importante separar CLI y PHP-FPM: Una prueba desde la línea de comandos no analiza automáticamente la misma configuración de tiempo de ejecución que una solicitud HTTP. Documenta los ajustes de OPcache y JIT que se utilizan realmente en ambos contextos. Su efecto y sus valores predeterminados dependen, entre otras cosas, de la versión de PHP; una suposición general no es suficiente para la comparación.

En Estado de la caché debe ser comparable. Una caché fría y una caché ya precalentada responden a preguntas diferentes; ambas pueden ser relevantes, pero deben evaluarse por separado. Lo mismo se aplica al volumen de datos y a los datos de prueba: si cambia el alcance del trabajo, ya no es posible atribuir con claridad una diferencia de tiempo al sistema.

Anota además el modelo de CPU, las vCPU asignadas y los límites de recursos visibles, así como la carga seleccionada y el número de repeticiones. Si se comparan deliberadamente dos paquetes de alojamiento diferentes, el resultado ofrece una visión de su configuración global respectiva. Las diferencias en cuanto al procesador, los límites, la base de datos o el almacenamiento en caché no deben interpretarse, sin un diagnóstico más detallado, únicamente como una ventaja de la CPU.

Seleccionar cargas de trabajo y métricas adecuadas

La elección de la prueba depende de la pregunta que quieras responder. Una Microbancada de pruebas Analiza una tarea de cálculo limitada; una prueba HTTP tiene en cuenta el recorrido a través de la pila web. Los resultados de SPEC complementan la comparación con pruebas estandarizadas del sistema que exigen un uso intensivo de la CPU, pero no sustituyen a una prueba de la propia aplicación PHP.

Para una única solicitud dinámica, elige una página o ruta de API representativa y empieza con un bajo nivel de paralelismo. La ruta debe ejecutar PHP realmente: una respuesta servida íntegramente desde una caché de páginas previa sería, aunque una prueba de caché válida, no dice mucho sobre el procesamiento de PHP.

En el caso de visitantes simultáneos, comprueba el mismo punto final con varios niveles de carga predefinidos. De este modo, se puede determinar si los tiempos de respuesta y el rendimiento satisfactorio varían a medida que aumenta el paralelismo. En una ruta con un uso intensivo de bases de datos, el conjunto de datos, la ubicación de la base de datos y el estado de la caché deben permanecer iguales entre las ejecuciones comparativas.

Puedes analizar de forma aislada con PHPBench una función de la aplicación que suponga una gran carga para la CPU, como, por ejemplo, un procesamiento de datos sin acceso a la red. Un mejor resultado solo indica, en un primer momento, una ventaja para esa función en las condiciones de ejecución seleccionadas. La prueba de la aplicación deberá demostrar si esto se traduce en una ventaja apreciable para una página completa.

Realizar una prueba de staging con wrk

Realiza las pruebas únicamente con autorización expresa en un entorno de pruebas aislado. Configura una ruta de lectura representativa y sin riesgos, y utiliza datos de prueba adecuados. Antes de comenzar, establece una carga máxima y unos criterios de interrupción, como la aparición de errores, tiempos de espera o la afectación de otros servicios.

El siguiente comando está pensado para un terminal en una instancia de staging local configurada expresamente para ello. La ruta preparada debe estar accesible en el puerto 8080; el comando genera una carga real y no está pensado para un sistema desconocido o en producción.

wrk -t2 -c4 -d30s --latency http://127.0.0.1:8080/

La llamada utiliza dos subprocesos del generador de carga, cuatro conexiones abiertas y una duración de 30 segundos. La opción --latency solicita un informe detallado sobre la latencia. En este caso, cuatro conexiones son un punto de partida elegido para este ejemplo, no una recomendación general sobre el número de visitantes o la capacidad de un servidor.

Sin embargo, la salida habitual de percentiles de wrk no incluye el p95. Para obtener un análisis reproducible del p95, guarda el siguiente script de Lua en el generador de carga como percentiles.lua. Los valores p50 y p95 de la estadística de latencia se expresan en microsegundos; al dividirlos por 1.000 se obtienen milisegundos.

function done(summary, latency, requests)
  io.write(string.format("p50: %.0f us\n", latency:percentile(50.0)))
  io.write(string.format("p95: %.0f us\n", latency:percentile(95.0)))
end

Para realizar la medición propiamente dicha, ejecuta la misma prueba de staging local mediante el script. La ruta del archivo se refiere a un terminal situado en el directorio donde se encuentra el archivo de script. Esta ejecución también genera carga; documenta los dos percentiles mostrados, junto con los errores y la calidad de la respuesta, que se ha comprobado por separado.

wrk -t2 -c4 -d30s --latency -s percentiles.lua http://127.0.0.1:8080/

Planifica una Fase de calentamiento antes de registrar las mediciones propiamente dichas. A continuación, repite cada nivel de carga establecido y, en la medida de lo posible, varía el orden de los sistemas de comparación. Anota cuánto tiempo ha durado el calentamiento y si la caché se encontraba en el estado deseado al inicio de la medición.

Aumenta el número de conexiones solo dentro de los límites acordados y comprueba los criterios de interrupción después de cada etapa. Observa también el generador de carga: si está saturado, puede limitar el resultado. Comprueba además los códigos de estado y el contenido de las respuestas; una página de error que se muestre rápidamente o una respuesta incorrecta no se consideran una solicitud de aplicación satisfactoria.

Documentar los niveles de carga y los resultados

Un informe de medición relaciona las cifras con las condiciones en las que se obtuvieron. Anota para cada ejecución el entorno, el punto final, el estado de la caché y el nivel de carga, junto con los resultados. La siguiente plantilla utiliza, entre otros, valores que proporcionan wrk o la página de estado de FPM; debes completar tú mismo la comprobación del contenido de la respuesta.

La mediana describe el valor central de los tiempos de respuesta observados. La p95 es el valor que no supera el 95 % de las respuestas medidas. En conjunto, ambas magnitudes indican si, además de una solicitud típica, también varía la parte más lenta de la distribución. Interprétalas siempre junto con los errores y los tiempos de espera agotados.

Hay que distinguir entre un número fijo de conexiones y una tasa de solicitudes predeterminada. En una prueba basada en conexiones, como la del ejemplo, las respuestas lentas pueden hacer que se generen menos solicitudes nuevas por segundo a través de las mismas conexiones. En ese caso, la latencia medida no describe directamente el comportamiento con una tasa de llegada que se mantenga alta.

Por lo tanto, compara únicamente puntos de carga suficientemente similares: la misma ruta y comprobación de respuesta, estados de caché comparables, así como el mismo modelo de carga y el mismo nivel de carga. Un p95 bajo con un bajo nivel de paralelismo no es directamente comparable con un p95 en condiciones de sobrecarga. Presenta varios resultados y su dispersión, en lugar de ofrecer un único valor favorable como resultado.

Analizar el FPM y los límites de recursos

Si, al aumentar la carga, crecen tanto la cola como el tiempo de respuesta p95, conviene echar un vistazo al grupo de PHP-FPM. Compara los valores actuales de active processes, idle processes y listen queue con el límite máximo configurado pm.max_children. Si todos los procesos permitidos están activos, no hay ninguno libre y hay solicitudes en espera, esto indica una Límite de la piscina o a procesos que llevan mucho tiempo en ejecución, pero no necesariamente a una CPU demasiado lenta.

El anuncio max children reached Por el contrario, documenta que se ha alcanzado antes el límite de procesos desde el inicio del pool. Por sí sola, esta cifra no indica ni que haya una cola activa ni que todos los procesos existentes estén ocupados en ese momento. Del mismo modo, el número máximo de procesos existentes no significa que todos estén activos.

Los trabajadores también pueden estar a la espera de consultas a la base de datos u otros servicios externos. Por lo tanto, compara el estado del grupo y la carga de la CPU con los tiempos de respuesta observados: una cola llena con una carga de la CPU baja sugiere que, en primer lugar, se deben analizar los tiempos de espera y la ocupación de los trabajadores. Aumentar el número de trabajadores no es automáticamente la solución, ya que los procesos adicionales también consumen recursos.

Los valores de estado de FPM se aplican al grupo correspondiente; los contadores se reinician al reiniciar el sistema. Por lo tanto, anota el grupo y la hora de reinicio en el registro de mediciones y compara los valores de los contadores únicamente dentro de un periodo de tiempo adecuado. Protege una página de estado activada contra el acceso no autorizado, ya que revela información operativa sobre el grupo.

En el caso de los servidores VPS y el alojamiento compartido, una vCPU asignada no equivale necesariamente a un núcleo físico exclusivo. Cuando se dispone de datos de cgroup-v2, se muestra cpu.max el límite de ancho de banda de la CPU configurado; cpu.stat puede incluir, entre otras cosas, contadores para Estrangulamiento incluidos. Los cambios en estos contadores durante una ejecución ayudan a diagnosticar una limitación efectiva.

Si es posible, comprueba también los cgroups de nivel superior: un límite establecido allí puede afectar al tiempo de computación disponible, incluso si la configuración visible a simple vista parece generosa. No todos los contadores reflejan completamente los límites heredados. Si esta información no figura en el paquete de alojamiento, la visibilidad limitada se considera expresamente una de las limitaciones del análisis.

Detectar la dispersión y los errores de medición

Una sola ejecución puede ofrecer una imagen aleatoriamente favorable o desfavorable. Repite los mismos niveles de carga en los momentos documentados y, en la medida de lo posible, varía el orden de los sistemas de comparación. Precisamente cuando se trata de recursos compartidos, el rendimiento disponible puede fluctuar; por lo tanto, además de un resultado típico, informa también del dispersión y el número de carreras.

Asegúrate de que las ejecuciones utilicen el mismo estado de caché y el mismo conjunto de datos. Una ejecución con la caché de páginas o de la base de datos «caliente» no es directamente comparable con una ejecución «fría». Si una respuesta aparentemente más rápida procede íntegramente de una caché de páginas, eso dice poco sobre la rapidez con la que PHP realiza el trabajo dinámico.

Un microbenchmark de la CLI tampoco es un resultado de FPM: se ejecuta en un contexto de ejecución diferente y puede utilizar otros ajustes de OPcache o JIT. Documenta por separado los ajustes realmente activos de ambos entornos de ejecución, en lugar de deducirlos a partir de la versión de PHP. Una ventaja observada en la microprueba no tiene por qué reflejarse en la misma medida en la prueba HTTP de la aplicación.

Cuenta únicamente las respuestas correctas en cuanto al contenido y que se hayan completado con éxito como parte del rendimiento efectivo. De lo contrario, las páginas de error rápidas o los tiempos de espera agotados pueden distorsionar considerablemente la comparación. Si observas desviaciones llamativas, comprueba también los tiempos de espera de la base de datos, los cambios en la caché y los límites de recursos visibles antes de atribuir la diferencia únicamente a la CPU.

El Comportamiento de sincronización también puede contribuir a la dispersión. La configuración de frecuencia más adecuada depende de la plataforma y de la carga; un ajuste genérico no sustituye a una comparación realizada en las mismas condiciones. La contribución a la Regulador de la CPU en servidores de alojamiento explica los contextos para un análisis más detallado.

Aprovechar los resultados para elegir un servicio de alojamiento web

Para consultas que suponen principalmente una carga para la CPU, la Tiempo por unidad de trabajo Un criterio de selección importante. Para ello, compara una función PHP representativa con un tiempo de ejecución documentado y comprueba a continuación si la ventaja también se aprecia en la ruta HTTP dinámica. Un microbenchmark describe, en un primer momento, únicamente el código probado, no toda la oferta de alojamiento.

Si esperas muchos visitantes simultáneos, una consulta individual rápida no es suficiente. Además, es fundamental saber cuántas respuestas correctas por segundo ofrece el sistema con un nivel de carga determinado y cómo se comporta la latencia p95 dentro del margen de error aceptado. Un sistema con mayor rendimiento no es automáticamente mejor para tu proyecto si sus respuestas lentas superan los requisitos.

En el caso de aplicaciones que dependen de bases de datos o de la caché, da prioridad al Prueba de funcionamiento más que una puntuación de CPU. Una ruta típica con un conjunto de datos comparable muestra cómo funciona la interacción de la pila en las condiciones seleccionadas. Un resultado SPEC puede complementar la preselección, pero describe un sistema sometido a prueba y no sustituye a una prueba de alojamiento web PHP.

Antes de realizar la selección, determina qué tiempos de respuesta, índices de error y niveles de carga son aceptables para la aplicación. A continuación, compara únicamente los resultados con un modelo de carga adecuado y un estado de caché comparable. Evalúa los distintos paquetes de alojamiento como configuraciones completas; a partir de la diferencia entre ellos no es posible determinar la proporción de la CPU sin un diagnóstico más detallado.

La decisión se aplica a la situación actual, no a futuras versiones de la aplicación ni a picos de acceso. Repite las pruebas pertinentes tras cualquier cambio significativo en PHP, la aplicación, la base de datos, la caché o los límites de recursos. De este modo, podrás comprobar si las reservas que antes eran suficientes siguen siendo suficientes en las nuevas condiciones.