Alojamiento compartido: cuándo son útiles las CPU rápidas a pesar de tener pocos núcleos

Diferenciar entre núcleos, subprocesos y tiempo de CPU

Un núcleo físico es una unidad de cálculo del procesador. El sistema operativo, por su parte, lo ve como procesadores lógicos como unidades ejecutables: en caso de multithreading simultáneo, varias de ellas pueden compartir los recursos de un núcleo físico. Por lo tanto, su número no permite determinar directamente cuántos núcleos independientes entre sí están disponibles para una cuenta de alojamiento.

En el alojamiento compartido, varias cuentas comparten el hardware de un servidor. Una tarifa puede limitar el tiempo de CPU que pueden consumir los procesos de una cuenta en un periodo determinado. Esto Presupuesto de tiempo de CPU es algo distinto al compromiso de utilizar un núcleo físico de forma exclusiva. Los cgroups de Linux constituyen una posible base técnica para establecer tales límites, pero no son la única forma posible de implementarlos.

Si en la tarifa figura, por ejemplo, „un vCore“ o „el 100 % de la CPU“, deberías consultar la definición del proveedor. Esta indicación puede referirse a un presupuesto de tiempo de cálculo, sin que se reserve de forma permanente un núcleo concreto. Tampoco se deduce del número total de núcleos del servidor anfitrión cuánta potencia puede utilizar realmente una sola cuenta al mismo tiempo.

En este contexto, la concurrencia se refiere al número de solicitudes o procesos que se pueden procesar en paralelo. Depende, entre otras cosas, de los límites de los procesos, la memoria y el presupuesto de CPU disponible. CloudLinux puede aplicar sus propios límites de recursos para ello; para saber si un plan utiliza esta técnica y cómo está configurada, debes consultarlo con el proveedor.

La limitación de recursos y el aislamiento de seguridad cumplen funciones diferentes: un límite controla el consumo, mientras que el aislamiento tiene por objeto restringir el acceso entre entornos. La Clasificación de CloudLinux Site Isolation y CageFS explica los mecanismos de seguridad correspondientes; de por sí, esto no implica una asignación concreta de CPU.

Por qué los GHz por sí solos no son determinantes

La frecuencia de reloj indica cuántos ciclos de reloj ejecuta un procesador por segundo. Una frecuencia más alta puede acelerar las tareas que dependen de la CPU, pero por sí sola no determina en qué medida se beneficia un sitio web de ello. Las diferentes arquitecturas de procesador realizan una cantidad de trabajo diferente por cada ciclo de reloj; además, el código concreto del programa también influye en el resultado.

A Rendimiento de un solo núcleo Además, la caché y el comportamiento de la memoria también influyen. Si un proceso tiene que esperar con frecuencia a que lleguen los datos, una frecuencia más alta puede tener menos efecto que en un cálculo en el que los datos ya están disponibles rápidamente. Una comparación basada únicamente en los GHz oculta estas diferencias y no sustituye a una prueba de rendimiento específica para cada aplicación.

Un ejemplo concreto de ficha técnica es el AMD EPYC 4564P: para este modelo, AMD indica 16 núcleos, 32 hilos, una frecuencia base de 4,5 GHz y una frecuencia máxima de hasta 5,7 GHz. Estos datos describen el procesador, no el rendimiento de un plan de alojamiento concreto.

El Aumento máximo No se trata ni de un valor constante garantizado ni de la frecuencia que se aplica en todo momento en todos los núcleos. Tampoco indican los datos del producto la rapidez con la que un determinado plan de alojamiento compartido procesa una solicitud de WordPress o PHP. Para ello, además del hardware, también influyen la configuración, la carga de trabajo y los límites del plan.

Cuando los proveedores con Alojamiento de CPU de alta frecuencia Por eso, cuando se anuncien, pregunta por el modelo concreto del procesador y el presupuesto de recursos disponible. Para que las comparativas de rendimiento sean significativas, se necesita además información sobre la versión del software, la configuración del servidor, la carga de trabajo y las condiciones de prueba. Sin estos datos, no es posible traducir de forma fiable un valor de GHz anunciado en un tiempo de respuesta más corto.

Solicitudes PHP y procesamiento paralelo

En una solicitud sincrónica típica, un trabajador PHP procesa los distintos pasos de su tarea PHP principalmente de forma secuencial. Una CPU más rápida puede acortar esta parte si realmente requiere un gran esfuerzo de cálculo. Sin embargo, si el trabajador espera principalmente a una base de datos o a un servicio externo, el beneficio de una mayor potencia del procesador para este tiempo de espera es limitado.

La formulación de la búsqueda PHP de un solo núcleo Por lo tanto, esto no significa que un sitio web completo solo pueda utilizar un núcleo. Varias solicitudes pueden ser procesadas en paralelo por varios trabajadores; además, el servidor web y la base de datos pueden funcionar al mismo tiempo. Lo decisivo es cuánto de este trabajo en paralelo permiten los recursos disponibles y la configuración correspondiente.

Con PHP-FPM, se limita pm.max_children el número de solicitudes que un grupo puede atender simultáneamente. Si se alcanza el límite, las solicitudes adicionales no pueden ser procesadas de inmediato por otro trabajador de ese grupo. Sin embargo, este límite no indica cuántos visitantes en total pueden utilizar un sitio web.

El Gestión de procesos PHP-FPM dispone de tres modos de funcionamiento: static mantiene un número fijo de trabajadores. dynamic ajusta su número en función de la demanda, según la configuración; ondemand Inicia los trabajadores cuando sea necesario. El modo de funcionamiento seleccionado determina, por tanto, cuándo los procesos están disponibles o cuándo se reinician.

Un mayor número de trabajadores no se traduce automáticamente en más tiempo de CPU. Además, necesitan memoria RAM y, si se ejecutan en paralelo, pueden alcanzar conjuntamente el límite de una cuenta. Para evaluar una CPU de alojamiento compartido Por lo tanto, el número de trabajadores y el presupuesto de recursos van de la mano. No todos los planes utilizan PHP-FPM ni permiten a los clientes modificar por sí mismos su configuración.

Cuota de CPU con carga paralela

A Cuota de CPU establece cuánto tiempo de procesamiento puede consumir un grupo de procesos en un intervalo de tiempo determinado. En Linux, cgroup v2 describe cpu.max este presupuesto y el período correspondiente. De este modo, la cuota no reserva automáticamente un núcleo físico exclusivo, sino que limita el tiempo de CPU total disponible para el grupo.

Ejemplo ilustrativo de cálculo, no se trata de una medición: un grupo recibe 100 milisegundos de tiempo de CPU por cada periodo de 100 milisegundos. Esto equivale, de media, al tiempo de cálculo de un procesador lógico que funciona a plena capacidad. Si dos procesos calculan simultáneamente en dos procesadores lógicos disponibles, teóricamente pueden agotar el presupuesto común tras unos 50 milisegundos de tiempo real.

Si se agota el presupuesto, los procesos pueden ralentizarse hasta el siguiente periodo. Por lo tanto, los dos trabajadores no disponen cada uno de un presupuesto propio de 100 milisegundos. El hecho de que se ejecuten realmente en paralelo, y cuándo lo hacen, depende, entre otras cosas, del programador, de las CPU disponibles y de su comportamiento; el ejemplo no predice ningún tiempo de respuesta concreto.

Para el análisis, cgroup v2 en cpu.stat entre otras cosas, contadores para Estrangulamiento listos. Si aumentan durante una fase de carga representativa, esto indica que se ha agotado la cuota. Sin embargo, una sola lectura del contador no basta para determinar qué solicitud se ha visto afectada ni si existen otros cuellos de botella.

Deberás aclarar con el proveedor si se puede acceder a estos archivos en el plan de tarifas y si son relevantes para la página web. El alojamiento compartido puede utilizar otros mecanismos: CloudLinux, por ejemplo, documenta sus propios límites LVE para la CPU y otros recursos. Por lo tanto, del ejemplo de Linux no se puede deducir ni la configuración concreta ni el comportamiento de cada cuenta de alojamiento.

CMS, tienda y tareas en segundo plano

En una página CMS sin caché, el servidor ejecuta la lógica de la aplicación para la solicitud y obtiene los datos necesarios. Si una gran parte del procesamiento recae en Funcionamiento de la CPU, un mayor rendimiento por núcleo puede acortar esta sección. Esto se aplica, por ejemplo, a los cálculos complejos en el código PHP, pero no necesariamente al tiempo total que tarda en cargarse la página.

Sin embargo, si esa misma solicitud depende principalmente de una consulta a una base de datos o de una API externa, el proceso PHP solo podrá beneficiarse de forma limitada de una CPU más rápida durante ese tiempo. Por lo tanto, lo que cuenta a la hora de tomar una decisión es el desglose del tiempo de respuesta del servidor: ¿cuánto tiempo se dedica al cálculo y cuánto a esperar a otros servicios?

Una tienda muestra por qué esta pregunta puede tener respuestas diferentes según la página. Las páginas públicas de productos se pueden guardar temporalmente como respuesta definitiva si se cumplen las condiciones adecuadas. Un Aciertos de caché puede evitar que PHP vuelva a procesar todo el código; por el contrario, el carrito de la compra y el proceso de pago suelen tener que tener en cuenta datos específicos y siguen siendo dinámicos.

Por lo tanto, un gran número de solicitudes simultáneas de finalización de compra puede suponer una mayor carga para los trabajadores o el presupuesto de CPU que el mismo número de visitas a páginas almacenadas en caché. El número de visitantes por sí solo no describe esta carga: lo decisivo es qué puntos finales se solicitan simultáneamente y con qué frecuencia se recurre a la caché. Además, en PHP-FPM, la configuración del pool limita pm.max_children el número de solicitudes atendidas simultáneamente.

Una importación que requiere un gran esfuerzo de cálculo en el backend puede, a su vez, beneficiarse de un trabajo individual más rápido. Si se ejecuta en paralelo a las solicitudes de los visitantes, es posible que los procesos compitan por el mismo presupuesto de tiempo de CPU. El hecho de que una tarea programada o una importación se asigne realmente al mismo grupo limitado depende del plan de tarifas y de su configuración; consulta al proveedor antes de tomar una decisión sobre la capacidad.

Para realizar una comparación significativa, debes analizar por separado estas cargas de trabajo: una solicitud dinámica típica, una fase con varias solicitudes simultáneas y, en su caso, la importación durante el funcionamiento del sistema. De este modo, podrás determinar más fácilmente si lo más importante es la velocidad de un paso concreto del proceso o la capacidad total disponible.

Comparar observaciones y cuellos de botella

Una respuesta lenta no indica necesariamente una causa. El siguiente resumen relaciona observaciones típicas con posibles causas que se pueden comprobar. Tiene en cuenta, en particular, los límites de tiempo de la CPU, el número limitado de trabajadores en PHP-FPM y la diferencia entre el código PHP almacenado y una respuesta ya generada.

Cada fila de la tabla es una Hipótesis, no es un diagnóstico definitivo. Las respuestas lentas en entornos paralelos pueden deberse, por ejemplo, a una reducción de la velocidad de la CPU, pero también pueden estar provocadas por trabajadores ocupados o por una base de datos en espera. Por lo tanto, comprueba, en la medida de lo posible, varias señales al mismo tiempo y para la misma carga de trabajo, en lugar de deducir un cambio de tarifa a partir de un único síntoma.

Al realizar el análisis, separa los Tiempo de respuesta Una consulta sobre el rendimiento: una respuesta individual más rápida no significa automáticamente que, ante un alto nivel de concurrencia, se procesen más consultas por segundo. Por el contrario, un sistema puede alcanzar un buen rendimiento y, aun así, hacer que las consultas individuales tengan que esperar más tiempo.

El tiempo de carga percibido de la página tampoco debe equipararse al tiempo de respuesta del servidor. Tras la respuesta, por ejemplo, pueden cargarse y procesarse en el navegador otros recursos. Una mejora de la CPU en el alojamiento solo afecta a la parte correspondiente al servidor; para que la comparación sea justa, el estado de la caché, la página solicitada y el paralelismo deben permanecer iguales.

En cuanto a la caché, también conviene distinguir entre los conceptos: OPcache almacena código PHP compilado y, de este modo, evita tener que volver a compilarlo. Por el contrario, una caché de páginas almacena una respuesta ya generada. Por lo tanto, una respuesta rápida de la caché no demuestra ni que las solicitudes dinámicas dispongan de recursos suficientes de CPU, ni que OPcache sustituya a la lógica de la aplicación.

Detectar los cuellos de botella y los tiempos de espera

Empieza el diagnóstico con solicitudes típicas de tu sitio web: por ejemplo, una página pública del CMS, una búsqueda y, en el caso de una tienda online, el proceso de pago. Anota si la respuesta correspondiente procede de la caché de la página. A continuación, compara las visitas individuales y un número de solicitudes simultáneas representativo de tu proyecto, en lugar de fijarte únicamente en el número total de visitantes.

Si es posible, separa los tiempo de CPU de la aplicación del tiempo de respuesta total y los tiempos de espera en la base de datos o en servicios externos. Si la parte correspondiente a la CPU es pequeña, un procesador más rápido solo podrá acortar una parte limitada de la llamada. Si no dispones de valores de medición adecuados, solicita al proveedor los registros, las métricas o un análisis adecuado disponibles.

Con una carga paralela, comprueba si los trabajadores disponibles están a plena capacidad y si los contadores de límites están aumentando. En PHP-FPM, limita pm.max_children las solicitudes atendidas simultáneamente por un grupo; que puedas ver este valor o la carga de trabajo depende del plan de tarifas. Los sistemas Linux cgroup-v2 pueden en cpu.stat entre otras cosas, mostrar los contadores de limitación. Un aumento en el contador es motivo para revisar con mayor detalle el presupuesto de la CPU y el periodo de medición.

Si se puede acceder a SSH y al archivo en cuestión, se muestra cat /proc/self/cgroup la asignación a un cgroup del proceso que realiza la llamada. Esto no implica que las solicitudes web se ejecuten en el mismo grupo. Aclara las rutas, los permisos y la interpretación con el proveedor; tampoco se pueden asignar de forma generalizada los códigos de error a un límite concreto de cada sistema de alojamiento compartido.

Comprobar la caché y comparar tarifas

Comprueba primero qué páginas públicas se pueden guardar de forma segura como respuesta completa. Una Caché de páginas puede evitar el procesamiento dinámico repetido en caso de que se produzca una coincidencia. Por el contrario, los contenidos personalizados, el carrito de la compra y el proceso de pago requieren una estrategia de caché adecuada para que los visitantes no reciban datos ajenos o obsoletos.

Otro enfoque consiste en reducir la carga de trabajo en caso de fallos de caché: analiza las consultas lentas a la base de datos y elimina el procesamiento dinámico innecesario. En el caso de un servicio externo, su tiempo de respuesta puede ser determinante; en ese caso, deberías analizar primero esa llamada, en lugar de dar por hecho que la causa es la CPU. El cambio que resulte más eficaz dependerá de cuál sea realmente la ruta lenta.

Hay que distinguirlo de OPcache: Almacena código PHP compilado, pero no sustituye ni a una caché completa de la página ni a la ejecución de la lógica de la aplicación. Comprueba la disponibilidad y la configuración en el entorno de ejecución web. La CLI tiene su propia configuración de OPcache; por lo tanto, un simple vistazo a la línea de comandos no basta para determinar la configuración de las solicitudes web.

Para comparar tarifas, debes contrastar las mismas consultas con las mismas versiones de software, un conjunto de datos comparable y un estado de caché registrado. Repite la comparación con el mismo nivel de paralelismo y ten en cuenta los recursos disponibles de CPU, trabajadores y memoria en cada caso. De lo contrario, las condiciones de la prueba podrían dar lugar a diferencias sin que ello permita extraer conclusiones fiables sobre el rendimiento del procesador.

Además, anota por separado cuánto tiempo tardan las respuestas individuales y cuántas solicitudes se procesan en un periodo determinado. Una tarifa puede parecer económica para una sola consulta, pero puede llegar a sus límites si hay una carga simultánea. Los valores de una comparación solo son válidos, en un primer momento, para la aplicación analizada y sus condiciones.

¿Una CPU más rápida o un presupuesto mayor?

Si una consulta dinámica representativa realiza principalmente trabajo de CPU y no hay limitaciones en cuanto a trabajadores, memoria o presupuesto de tiempo, es preferible una mayor Potencia por núcleo Una opción de tarifa plausible. Puede acortar la parte de cálculo de la consulta individual. Sin embargo, el impacto que esto tenga en la respuesta completa sigue dependiendo de la aplicación y de sus tiempos de espera.

Por el contrario, si los datos indican una ralentización o que los trabajadores están saturados ante varias solicitudes simultáneas, comprueba si es necesario un mayor Presupuesto de recursos. Aumentar el tiempo de CPU puede ser útil cuando se ha alcanzado el límite de la cuota; al mismo tiempo, los trabajadores adicionales necesitan suficiente memoria y tiempo de cálculo. Si el cuello de botella lo constituyen la base de datos o los servicios externos, un mayor presupuesto de CPU por sí solo no es una solución fiable.

Antes de realizar un cambio, merece la pena compararlo con la optimización de la instalación actual. Una caché de páginas adecuada o una consulta mejorada pueden reducir el trabajo dinámico sin que necesites pasar inmediatamente a un plan de tarifas superior. Repite el diagnóstico tras un cambio en condiciones similares, para que puedas distinguir su efecto de otras influencias.

A El VPS como alternativa al alojamiento compartido Suele ofrecer un mayor control sobre el software y la configuración, pero también conlleva una mayor responsabilidad en materia de seguridad, actualizaciones y planificación de la capacidad. Las CPU virtuales no son núcleos físicos exclusivos a menos que el proveedor lo garantice expresamente. Por lo tanto, comprueba también en ese caso la asignación concreta de recursos y las condiciones del contrato.

Antes de tomar una decisión, pregunta al proveedor por el modelo de procesador, la definición del presupuesto de tiempo de CPU y cómo se gestionan los picos de carga. Aclara también cuáles son los límites de trabajadores y de memoria, si los trabajos en segundo plano comparten el mismo presupuesto y qué contadores de límites puedes consultar. Solo con esta información podrás valorar adecuadamente el rendimiento de la CPU anunciado para tu tarifa concreta.