Las listas de funcionalidades superficiales rara vez ofrecen una visión completa a la hora de evaluar el alojamiento administrado para WordPress con fines de desarrollo. Es necesario comprender cómo afecta la asignación de hilos PHP al manejo de solicitudes simultáneas, cómo funcionan conjuntamente las múltiples capas de caché para reducir la carga de la base de datos y si la contenedorización realmente evita problemas en condiciones reales.
Esta guía desglosa la arquitectura técnica de Kinsta para la gestión de hilos PHP, el almacenamiento en caché multicapa y el aislamiento de contenedores. También incluimos citas de Nikola Djuric, ingeniero de soporte senior del equipo de Kinsta, sobre las complejidades de la gestión de hilos PHP.
Empecemos por cómo gestiona PHP las peticiones.
Comprender los hilos PHP y por qué son importantes para el rendimiento de WordPress
Los hilos de PHP procesan las peticiones entrantes no almacenadas en caché. Cada hilo gestiona una petición a la vez, por lo que el número de hilos disponibles afecta directamente al número de visitantes que tu sitio puede atender simultáneamente.
Cuando un visitante carga una página no almacenada en caché, envía un formulario o añade un artículo a su carrito:
- El servidor web recibe la petición y se la pasa a PHP-FPM.
- PHP asigna la petición a un hilo disponible.
- Ese hilo ejecuta el código PHP, obtiene datos de la base de datos y genera una salida dinámica.
- Una vez completado, el hilo vuelve a estar disponible.
La mayoría de la gente no sabe que una petición no almacenada en caché utiliza un hilo de PHP y que la velocidad de procesamiento depende del tiempo de respuesta de PHP más MySQL.
Las peticiones almacenadas en caché se saltan todo este proceso (no tocan PHP en absoluto), por lo que las tasas de HIT en caché son el factor más importante a la hora de determinar cuántos hilos necesitas realmente.
Los sitios de WooCommerce, los paneles de control de membresía, el tráfico de la API REST y las configuraciones headless evitan el caché con mucha más frecuencia, lo que significa que consumen hilos rápidamente.
Por ejemplo, si la respuesta media de tu API tarda 250 milisegundos, cada subproceso puede procesar cuatro solicitudes por segundo. Con ocho subprocesos, tu rendimiento teórico máximo es de 32 solicitudes por segundo. Sin embargo, esto es sólo si cada solicitud se completa exactamente en 250 ms.
Cómo consume el tráfico concurrente los hilos PHP
El número de hilos es más importante durante el tráfico simultáneo. Si tu sitio tiene cuatro hilos y recibe seis solicitudes simultáneas sin almacenar en caché:
- Cuatro peticiones comienzan a procesarse inmediatamente.
- Dos esperan un hilo libre.
Si llega nuevo tráfico más rápido de lo que los hilos pueden liberarse, el retraso crece.
Las consultas lentas a la base de datos empeoran la situación. Por ejemplo, una consulta a la base de datos que tarda 10 segundos bloquea un hilo durante todo ese tiempo. Si recibes tres peticiones simultáneas que desencadenan consultas lentas, habrás consumido tres subprocesos durante un total de 30 segundos. Durante ese tiempo, tus hilos restantes manejan el resto del tráfico.
Cuando añades filtros de WooCommerce, páginas de cuenta o flujos de pago, la presión de los hilos aumenta aún más.
En cuanto a los hilos PHP, los sitios web sencillos solo necesitan cuatro. Sin embargo, para el comercio electrónico, cualquier número inferior a seis es bajo debido a la elevada tasa de bypass del caché.
La relación entre el número de hilos y el tiempo de ejecución
Una forma aproximada de estimar las necesidades de hilos:
Hilos necesarios ≈ (Peticiones sin caché por segundo × Tiempo medio de ejecución)
Basándonos en esto, un sitio con 10 peticiones no almacenadas en caché por segundo y un tiempo medio de ejecución de 0,5 segundos necesita aproximadamente cinco hilos para manejar la carga sin hacer cola.
Esto explica por qué añadir simplemente más hilos no garantiza un mejor rendimiento. Si las consultas lentas a la base de datos hacen que tu tiempo medio de ejecución pase de 0,5 segundos a dos segundos, tus necesidades de hilos se cuadruplican.
La solución es una ejecución más rápida del código. Optimizar las consultas, reducir las llamadas a API externas e implementar un almacenamiento en caché de objetos adecuado puede reducir drásticamente el tiempo de ejecución y los hilos necesarios para gestionar tu tráfico.
Asignación de hilos PHP en los planes de Kinsta
Kinsta asigna hilos PHP en función de los recursos de CPU y RAM disponibles en el contenedor de cada sitio (cada sitio Kinsta se ejecuta en su propio contenedor LXD, por lo que los recursos están aislados).
Patrones generales entre planes:
- Nivel básico: 2-4 hilos a 256 MB por hilo. Esto es ideal para blogs y sitios de contenido estático con altos índices de visitas al caché.
- Nivel medio: 6-8 hilos a 256 MB por hilo, con algunos planes para agencias que aumentan la memoria a 512 MB por hilo.
- Nivel superior: 10-16 hilos con 512 MB por hilo, adecuado para sitios complejos o con mucho tráfico.
- Multisitio: 8-14 hilos, dependiendo del nivel.
Puedes ajustar la asignación de hilos dentro de MyKinsta > Info > Rendimiento PHP, aumentando el pool de memoria o el número de hilos en función de los patrones de tráfico de tu sitio.
Esta flexibilidad te permite ajustar PHP a tu carga de trabajo real, en lugar de confiar en los valores predeterminados.
Estimar los requisitos de hilos PHP para tu sitio
Los distintos tipos de sitios necesitan asignaciones de hilos personalizadas en función de cuánto tráfico se salta (bypass) el caché:
- Sitios de contenido estático. 2-4 hilos suelen ser suficientes porque las páginas en caché sirven a casi todo el tráfico.
- Tiendas WooCommerce. Empieza con 8-12 hilos dependiendo del tamaño del catálogo, la complejidad del filtrado y el volumen de compras.
- Aplicaciones con muchas APIs o headless. Estimación basada en el tiempo de ejecución (por ejemplo, solicitudes de 0,25 s = aproximadamente 4 por segundo por hilo).
- Sitios de membresía y plataformas LMS. Los usuarios identificados se saltan la caché por completo, por lo que se comportan de forma similar a un e-commerce.
Las analíticas de MyKinsta te ayuda a identificar tus patrones actuales de uso de hilos.
Si observas colas de peticiones o errores de tiempo de espera durante las ventanas de alto tráfico, es probable que tu asignación de hilos necesite un ajuste.
Qué ocurre cuando superas tu límite de hilos PHP
El agotamiento de los hilos sigue un patrón predecible:
No hay cola para las solicitudes. El número de hilos PHP que tiene tu sitio determina cuántas solicitudes sin almacenar en caché se pueden procesar a la vez. Cuando llega una solicitud y no hay ningún hilo disponible, esta espera a que se libere uno. Si eso no ocurre con la suficiente rapidez, aparecerán errores 502 o 503 Bad Gateway
Síntomas comunes:
- Las peticiones se ponen en cola dentro de NGINX/PHP-FPM cuando todos los hilos están ocupados procesando.
- Los usuarios finales experimentan retrasos, como iconos de carga (spinners) persistentes, procesos de pago lentos o llamadas AJAX fallidas.
- Aparecen errores 502 o 504 una vez que la capacidad de la cola se llena por completo.
- La recuperación suele producirse en 30-120 segundos después de que finalicen las funciones lentas y el caché se «calienta».
Las consultas lentas a la base de datos son la causa más común.
Las consultas lentas a la base de datos tardan más tiempo en ser procesadas por los hilos de PHP y así es como suelen acabar con el rendimiento del sitio.
Las llamadas a API externas crean problemas similares. Las pasarelas de pago, los servicios de cálculo de impuestos y las APIs de envío suelen bloquear los hilos durante el pago.
Para diagnosticar el agotamiento de los hilos es necesario examinar múltiples fuentes de datos. La herramienta APM de Kinsta rastrea las solicitudes lentas e identifica los cuellos de botella, mientras que los registros de consultas lentas revelan los problemas de rendimiento de la base de datos. Las métricas de la cola de Nginx muestran los patrones de acumulación de solicitudes y las relaciones HIT/MISS del caché indican si el almacenamiento en caché está funcionando.
La solución es optimizar el tiempo de ejecución:
- Las consultas lentas a la base de datos necesitan indexación, optimización de las consultas o reducción del número de consultas.
- Los plugins pesados pueden requerir la sustitución por alternativas más ligeras.
- Las tareas Cron deben desplazarse a las horas de menor actividad.
- Las llamadas a API externas se benefician del uso de caché, del procesamiento en segundo plano (background processing) o de interruptores (circuit breakers).
La optimización debe venir antes de añadir más hilos. Aumentar el número de hilos sólo ayuda cuando el tiempo medio de ejecución está bajo control.
Arquitectura de caché multicapa de Kinsta
El almacenamiento en caché reduce la frecuencia con la que las peticiones llegan a PHP. Kinsta utiliza tres capas:
- Edge caching sirve contenido estático desde ubicaciones globales cercanas a los visitantes.
- Caché de objetos con Redis reduce la carga de la base de datos almacenando los resultados de las consultas en la memoria.
- CDN de Kinsta entrega activos estáticos desde ubicaciones edge distribuidas.
Estas capas trabajan juntas para minimizar las peticiones que llegan a tus hilos PHP y a la base de datos.
Edge caching a través de Cloudflare
La red edge global de Cloudflare sirve páginas HTML en caché basadas en claves de caché que tienen en cuenta:
- URL y parámetros de consulta
- determinadas cookies
- estado de autenticación
- cookies de carrito/sesión de WooCommerce
Esto evita que se sirva contenido personalizado a los usuarios equivocados.
Las reglas de bypass de caché también evitan el almacenamiento en caché de contenido dinámico que debe permanecer fresco, como las áreas de administración de WordPress o las páginas de pago de WooCommerce.
La diferencia de rendimiento significa que las peticiones almacenadas en caché edge eluden completamente los hilos de PHP y nunca llegan a tu instalación de WordPress. Un sitio en el que el 80% de las peticiones llegan al caché edge sólo necesita hilos PHP para el 20% restante del tráfico.
Caché de objetos con Redis
Kinsta proporciona Redis como add-on en lugar de requerir plugins de terceros, lo que puede garantizar que Redis funcione con el sistema de caché de objetos de WordPress.
Redis almacena los resultados de las consultas a la base de datos en la memoria, por lo que el servidor no necesita repetir la ejecución de esas consultas.
Redis es un multiplicador del rendimiento para sitios bien estructurados — no un parche para consultas pesadas o tablas sin indexar.
Redis ayuda cuando:
- Muchos usuarios cargan los mismos datos (entradas, productos, categorías)
- Las tiendas WooCommerce realizan búsquedas de categorías o comprobaciones de productos
- Las APIs repiten consultas idénticas
Sin embargo, Redis no acelera la lógica PHP intrínsecamente lenta, bloquea las llamadas a APIs externas ni optimiza los bucles mal optimizados.
CDN de Kinsta para la entrega global de recursos
La CDN de Kinsta sirve recursos estáticos desde más de 260 ubicaciones globales. Este enfoque reduce la latencia para los visitantes internacionales y elimina las cargas de recursos estáticos desde tu servidor de origen. También convierte automáticamente las imágenes al formato WebP cuando los navegadores lo admiten.
Los encabezados de control de caché determinan cuánto tiempo almacena la CDN los recursos. Puedes configurar la duración del caché para diferentes tipos de recursos en función de su frecuencia de cambio. El CSS principal, por ejemplo, puede tener un periodo de caché prolongado. La purga de la caché para ambas capas se gestiona a través de MyKinsta, ya sea de forma individual o conjunta.
Entre la CDN de Kinsta y Edge Caching, puedes gestionar páginas HTML, contenido dinámico y recursos estáticos. Juntos, garantizan que la mayoría de las solicitudes nunca lleguen a tu servidor de origen ni consuman hilos PHP.
Aislamiento de contenedores: resolver el problema del vecino ruidoso
Los entornos de alojamiento compartido suelen sufrir cuando un sitio consume demasiados recursos. Kinsta evita por completo esta situación mediante el aislamiento de contenedores LXD, que proporciona a cada sitio lo siguiente:
- CPU dedicada
- RAM dedicada
- sistema de archivos aislado
- stack de software independiente
Otros sitios no pueden «robar» tus recursos, y los problemas en un contenedor no pueden afectar a los demás.
Los contenedores se ejecutan en hardware informático optimizado, lo que garantiza un rendimiento estable y predecible incluso durante los picos de tráfico.
Adaptación a las necesidades de tu sitio
Cuando tu sitio necesite sistemáticamente más recursos de los que proporciona tu plan actual, tienes opciones para escalar verticalmente dentro de tu contenedor.
Por ejemplo, el add-on de rendimiento PHP proporciona hilos y memoria adicionales para los sitios que necesitan más potencia de cálculo.
También puedes pasarte a un plan de nivel superior, aumentando así los recursos asignados a tu contenedor, el número de hilos y la memoria por hilo. Esto es adecuado para los sitios que puedan estar superando la capacidad de su plan actual.
La clave está en comprender si necesitas optimización o capacidad adicional. Si tus hilos se saturan pero el uso de la CPU sigue siendo bajo, el problema son las consultas lentas o las llamadas a APIs externas, no el número de hilos. Añadir hilos sin abordar la ejecución lenta simplemente permite que más peticiones esperen más tiempo a que se completen los procesos lentos.
Resumen
La gestión de hilos de PHP, el almacenamiento en caché multicapa y el aislamiento de contenedores desempeñan un papel fundamental en el rendimiento de WordPress a escala. Comprender cómo funcionan los hilos y cómo el almacenamiento en caché reduce la carga que manejan facilita la elección del plan adecuado y la optimización eficaz de tu sitio.
Si estás listo para ver cómo la infraestructura de Kinsta gestiona tus cargas de trabajo de WordPress, explora hoy mismo la plataforma de alojamiento administrado de Kinsta.
