Ir al contenido 
trabajadores php son procesos independientes que ejecutan código PHP y procesan así todas las peticiones dinámicas de un sitio web. Si llegan al servidor demasiadas peticiones no almacenadas en caché al mismo tiempo, los trabajadores existentes ocupan todas las ranuras, se forma una cola y el cuello de botella provoca largos tiempos de respuesta, TTFB-consejos y errores.
Puntos centrales
Resumo los siguientes mensajes clave de forma compacta para que pueda tomar rápidamente las decisiones adecuadas para Actuación y capacidad.
- Definición deLos PHP Workers procesan las peticiones en serie, sólo una petición por worker.
- Cuello de botellaDemasiados pocos trabajadores crean colas, el TTFB aumenta y los tiempos de espera son inminentes.
- RecursosLos Workers requieren núcleos de CPU; una proporción incorrecta provoca cambios de contexto.
- Almacenamiento en cachéCuanto mayor sea el número de accesos desde la caché, menor será la carga de los trabajadores durante los picos de tráfico.
- EscalaAjuste el número de trabajadores al perfil de la página, los plugins y las interacciones.
¿Qué son los PHP Workers en el contexto del alojamiento?
Comprendo Trabajadores PHP como servidores digitales que atienden cada solicitud dinámica individualmente. Un trabajador lee el script PHP, lanza consultas a la base de datos y las utiliza para construir el HTML para el navegador. Si se está ejecutando una tarea, el trabajador permanece vinculado hasta su finalización y sólo entonces vuelve a estar disponible, en paralelo no funciona. En WordPress, los workers también realizan tareas recurrentes como cron jobs, envío de correos electrónicos y comprobaciones de seguridad. Precisamente por eso, el número y la calidad de los trabajadores influyen en la velocidad percibida de un sitio web. sitio web masiva.
¿Cuándo y por qué se produce el cuello de botella de trabajadores?
Se produce un cuello de botella en cuanto llegan al mismo tiempo más peticiones no almacenadas en caché que Trabajador están disponibles. Cada solicitud adicional acaba entonces en una cola y espera un hueco libre. Esto aumenta el tiempo hasta el primer byte, prolonga los tiempos de carga y puede provocar la cancelación de los procesos de compra. En las tiendas o áreas de miembros, los contenidos personalizados agravan la situación porque la caché no puede dar muchas respuestas, lo que puede ralentizar el proceso de pago. Carga directamente a los trabajadores. En esta situación, consigo el mayor efecto con un almacenamiento en caché sensato, plug-ins optimizados y una proporción armoniosa entre trabajadores y CPU.
Reconocer los síntomas: Leer correctamente las métricas y los registros
Primero miro TTFBporque los valores crecientes indican colas. Errores como 504 Gateway Timeout se producen cuando las peticiones permanecen bloqueadas durante demasiado tiempo y se cancelan con fuerza. En el panel de hospedaje, reconozco las colas a través de altos números de procesos con simultáneamente baja utilización de la red, lo cual es típico para peticiones bloqueadas. Trabajador es. Los registros de acceso muestran entonces muchas peticiones simultáneas a rutas no almacenadas en caché, como la cesta de la compra, la caja o los paneles personales. Si los tiempos de respuesta en el backend aumentan al mismo tiempo, las acciones de administración pesadas suelen bloquear a los trabajadores individuales durante más tiempo que necesario.
Diferenciación importante: servidor web frente a PHP-FPM
Hago una clara distinción entre los trabajadores del servidor web (por ejemplo, NGINX / Apache) y Trabajadores PHP-FPM. Gracias a Keep-Alive y HTTP/2, el servidor web puede multiplexar muchas conexiones y servir activos estáticos de forma extremadamente paralela. Sin embargo, el verdadero cuello de botella surge en PHP-FPM, donde cada proceso hijo procesa exactamente una solicitud. Aunque el navegador abra decenas de peticiones en paralelo, el número de procesos PHP limita el procesamiento simultáneo de rutas dinámicas. Esta distinción explica por qué las páginas con muchos archivos estáticos parecen rápidas, mientras que los puntos finales individuales y dinámicos (checkout, login, REST API) siguen atascándose.
Número óptimo de trabajadores: núcleos de cálculo, RAM y perfil de la aplicación
El número razonable de trabajadores depende de la proporción de páginas dinámicas, el panorama de plugins y la disponibilidad de Núcleos de CPU off. Nunca planifico un número de trabajadores muy superior al de núcleos de la CPU, porque el cambio permanente de contexto aumenta la latencia. De dos a cuatro trabajadores suelen ser suficientes para blogs pequeños, mientras que las tiendas activas y los LMS requieren bastante más. El factor decisivo sigue siendo la interacción: más trabajadores sin reservas de CPU no aportan ningún beneficio. Aceleración. Por eso pruebo con carga, mido TTFB y compruebo si el taco desaparece antes de seguir mejorando.
| Escenario | Sin caché | Trabajador | Núcleos de CPU | Efecto | Acción |
|---|---|---|---|---|---|
| Blog con caché | Muy bajo | 2-4 | 2-4 | Entrega rápida | Mantener caché, Plugins adelgazar |
| WooCommerce con consejos | Medio-alto | 6-12 | 4-8 | Tiempos de espera cortos | Aliviar la salida, Trabajador aumentar |
| Miembros/LMS | Alta | 8-16 | 8-16 | Menos tiempos muertos | Personalización de la caché, CPU apriete |
| Aplicación intensiva en API | Alta | 8-20 | 8-20 | Más incluso TTFB | Optimice las consultas, Límites configure |
Reglas generales de acotación
Para tener una primera sensación, calculo con la aproximación simple: Trabajadores necesarios ≈ Peticiones simultáneas no almacenadas en caché. Esta simultaneidad se calcula multiplicando la frecuencia de peticiones por el tiempo medio de procesamiento. Ejemplo: 10 peticiones/s con 300 ms de tiempo de servicio resultan en unas 3 peticiones PHP simultáneas. Si preveo reservas de seguridad y picos cortos, duplico este valor. Importante: Esta cifra debe ser Núcleos de CPU y RAM en forma; un trabajador sin tiempo de CPU no es más que otro trabajador en espera.
Calcule correctamente su presupuesto de almacenamiento
Cada proceso PHP-FPM consume RAM, dependiendo de Versión PHPactivo Opcache y los plugins cargados. Mido la huella real bajo carga (ps/top) y la multiplico por pm.max_hijosañadir servicios de servidor web, base de datos y caché. Así evito el swapping y el OOM killer. Como norma, mantengo 20-30% de buffer RAM libre. Si el consumo por proceso aumenta significativamente, lo interpreto como una señal para Plugin dietamenos extensiones o ajustes de memory_limit más restrictivos por pool.
El caché como capa de alivio
Cuanto más aprendo del Cache menos energía consumen los trabajadores. La caché de páginas, la caché de objetos y la caché de bordes reducen drásticamente la ejecución de PHP. Encapsulo partes dinámicas como el carrito de la compra o bloques personalizados con ESI o Ajax para que el resto permanezca en caché. Si quieres profundizar, puedes encontrar Almacenamiento en caché del servidor Guía de estrategias útiles para NGINX y Apache que realmente alivian a los trabajadores. Así es como reduzco notablemente el TTFB y mantengo el Tiempo de respuesta baja bajo carga.
También tengo en cuenta Invalidación de la caché y estrategias de calentamiento: Después de las implantaciones o de cambios importantes en los productos, caliento las páginas críticas y las rutas API. En las tiendas, cargo las páginas de categorías, los productos más vendidos, la página de inicio y las precargas de pago para amortiguar los picos de arranque en frío. En las cachés de objetos, presto atención a las estrategias de limpieza de claves para no descartar hotsets innecesariamente.
Errores típicos y trampas caras
Muchos sospechan inicialmente de una falta de RAM o la CPU como principal problema, aunque la cola de los trabajadores es el verdadero cuello de botella. Por lo tanto, compruebo si las páginas en caché siguen siendo rápidas y sólo las rutas dinámicas se descontrolan. Otro concepto erróneo es "más workers lo soluciona todo", que sin núcleos adicionales se convierte en altos cambios de contexto y peor latencia. Del mismo modo, los plugins malos enlazan un trabajador durante un tiempo excesivamente largo, lo que aumenta la latencia percibida. Actuación se deteriora. Por eso reduzco los complementos, optimizo las consultas a la base de datos y escalo los recursos al unísono.
Puntos de acceso específicos de WordPress
- admin-ajax.php y wp-jsonMuchas llamadas pequeñas se acumulan y bloquean a los trabajadores; agrupo las peticiones y establezco cachés sensibles.
- API de latidos: En el backend, limito las frecuencias para que no haya innecesariamente muchas peticiones simultáneas.
- WooCommerce wc-ajaxLas comprobaciones de la cesta de la compra, los envíos y los cupones a menudo no se almacenan en caché; reduzco las llamadas a API externas y optimizo los ganchos.
- Transitorios y OpcionesLas opciones de autocarga sobrecargadas o las costosas regeneraciones transitorias amplían el tiempo de ejecución de PHP y, por tanto, el compromiso de ranura.
Práctica: De tres a ocho trabajadores - sin atascos
Suponiendo que una tienda sólo opere tres Trabajador y experimenta atascos por la noche. Primero analizo las rutas que no proceden de la caché y mido el TTFB bajo carga. Después activo la caché de páginas y objetos limpios y sólo externalizo las áreas personalizadas. A continuación, aumento los trabajadores a ocho y, al mismo tiempo, añado dos Núcleos de CPU libre. En la siguiente prueba de carga, las colas disminuyen y la tasa de errores baja significativamente.
Opcionalmente, también suavizo los picos estableciendo límites conservadores para los puntos finales caros en el servidor web (por ejemplo, bajos upstreams simultáneos para checkout), mientras entrego contenido estático y en caché a velocidad ilimitada. De este modo, se reduce la presión sobre el conjunto de FPM y se estabiliza el rendimiento de la red. TTFB en general, aunque las acciones individuales de los usuarios sean brevemente más lentas.
Supervisión y pruebas de carga: herramientas que utilizo
Sigo TTFB, el tiempo de respuesta y la tasa de error a intervalos cortos para detectar la congestión en una fase temprana. Para la carga sintética, utilizo herramientas como K6 o Loader porque generan picos realistas. Los registros de aplicaciones ayudan a identificar las consultas lentas y las llamadas a API externas que atascan a los trabajadores. También compruebo las páginas de estado de PHP FPM para vigilar los slots ocupados, en espera y libres. Si los slots se llenan permanentemente, aumento los trabajadores y CPU paso a paso y compruebe cada paso con una carga de prueba.
Interpretar las métricas de forma fiable
- máximo de niños alcanzadosSe ha alcanzado el límite superior; las peticiones están esperando - es hora de más trabajadores o de un almacenamiento en caché más rápido.
- cola de escucha: Una cola creciente confirma la congestión frente al FPM; compruebo la configuración del servidor web y del upstream.
- request_slowlog_timeout y slowlog: Identifica las ubicaciones exactas de las peticiones donde se adjuntan los trabajadores.
- tiempo_de_respuesta_anterior en los registros del servidor web: Muestra cuánto tiempo ha estado respondiendo PHP; correlaciono con hora_solicitud y códigos de estado (502/504).
Interpretar correctamente las señales específicas de actualización
Si el TTFB Si hay un aumento notable del tráfico a pesar del almacenamiento en caché activo, suele haber una falta de capacidad de los trabajadores. Si hay frecuentes errores 504 durante acciones como el checkout o el login, hay verdaderos atascos de tráfico. Más pedidos simultáneos, campañas espontáneas o lanzamientos justifican trabajadores adicionales para que las transacciones se desarrollen sin problemas. Si se produce el estado de error 503, merece la pena echar un vistazo a esta guía para Error 503 de WordPressporque los procesos y límites defectuosos producen efectos similares. A continuación, decido si utilizar Worker, CPU o tiempos muertos.
Configuración: PHP-FPM y límites sensibles
Con PHP-FPM determino con pm.max_hijos el número máximo de procesos simultáneos y, por tanto, el límite superior de los trabajadores. Utilizo pm.start_servers y pm.min/max_spare_servers para controlar la rapidez con la que la capacidad está disponible. pm.max_requests protege contra las fugas de memoria reiniciando los procesos después de X peticiones. request_terminate_timeout asegura los procesos largos para que un trabajador no se quede colgado para siempre y bloquee los slots, que configuro cuidadosamente para las rutas de salida. Estos tornillos de ajuste tienen un efecto directo sobre las colas, así que sólo los cambio junto con Pruebas.
Elijo el correcto pm-modo consciente: dinámico para cargas fluctuantes, a la carta para cargas muy esporádicas en instancias pequeñas y estático para picos constantemente altos cuando la CPU y la RAM están claramente reservadas. También activo Opcache con suficiente memoria y revalidar los scripts de forma eficiente para que los trabajadores necesiten menos CPU por petición. Con request_slowlog_timeout y slowlog Encuentro puntos calientes en el código sin ampliar el pool. Compruebo si el socket FPM como Enchufe Unix o TCP está conectado; localmente prefiero sockets, a través de contenedores/hosts a menudo TCP.
Lista de comprobación para tiendas, afiliaciones y LMS
Para las tiendas considero dinámico Páginas como la cesta de la compra, la caja y "Mi cuenta", y reduzco las llamadas externas. En las áreas de miembros, compruebo que no haya consultas superfluas en cada perfil y panel de control. En el sistema de gestión de aprendizaje, utilizo la caché de objetos para las listas de cursos y muestro los indicadores de progreso de forma eficiente. En todos los casos, mi objetivo es realizar pocas peticiones breves por acción para que los trabajadores vuelvan a estar libres rápidamente. Sólo cuando esta tarea está hecha amplío los trabajadores y CPU en paralelo.
Sesiones, bloqueos y trampas de concurrencia
Presto atención a los bloqueos de sesión, que funcionan en serie por sesión de usuario por defecto en PHP. Si se ejecutan acciones costosas (por ejemplo, devoluciones de llamada de pago) durante la misma sesión, se bloquean más peticiones de este usuario, lo que provoca picos de TTFB y los cuelgues percibidos. Minimizo el uso de sesiones, sólo almaceno lo esencial en sesiones y cambio a gestores de alto rendimiento (por ejemplo, en memoria). En WooCommerce, presto atención a las sesiones y a las tormentas transitorias en la cesta de la compra.
Base de datos y servicios externos como multiplicadores
A menudo lento Consultas SQL o los límites de velocidad de las API externas afectan al trabajador. Optimizo los índices, reduzco las consultas N+1, establezco cachés de consulta (caché de objetos) y limito las llamadas externas con tiempos de espera y lógica de reintento. Si los servidores de pago, despacho o licencias se vuelven lentos, limito deliberadamente el paralelismo en estas rutas para que todo el grupo no esté esperando. Esto deja huecos libres para otras acciones de los usuarios.
Selección de proveedores y ajuste del alojamiento con vistas a los trabajadores
Prefiero los planes de alojamiento en los que puedo Trabajadores PHP de forma flexible y ampliar los núcleos de CPU en paralelo. Los proveedores de alto rendimiento ofrecen niveles de caché limpios, almacenamiento NVMe rápido y métricas claras en el panel. Como introducción a la evaluación técnica, el Guía de alojamiento PHPque haga tangibles los criterios centrales y las opciones. Para mí es importante que la asistencia no se interrumpa durante los picos de tráfico, sino que la capacidad esté disponible sin necesidad de reiniciar. Así mantengo TTFB, tasa de error y Rendimiento en equilibrio.
Plan de picos y protección contra la carga de bots
Estoy de acuerdo de antemano en una vía de escalada: ¿con qué rapidez pueden los trabajadores y CPU ¿quién controla qué tiempos de espera pueden crecer temporalmente? Al mismo tiempo, minimizo las cargas de bots y spam mediante límites de velocidad razonables en los puntos finales dinámicos. Cada solicitud innecesaria que se rechaza es un puesto de trabajo libre para clientes reales.
Para llevar
Trabajadores PHP decidir la rapidez con la que reaccionan las páginas dinámicas bajo carga, ya que cada proceso sólo gestiona una petición a la vez. Minimizo la carga con un almacenamiento en caché coherente, elimino los plugins que bloquean y establezco una proporción razonable entre trabajadores y CPU. En las horas punta, aumento cuidadosamente el número de trabajadores y compruebo si la cola desaparece y el TTFB desciende. Los registros, el estado de FPM y las pruebas de carga me permiten saber si estoy escalando correctamente o si necesito ajustar los tiempos de espera. Si tienes estas palancas bajo control, evitas los cuellos de botella, proteges las transacciones y garantizas un tiempo de procesamiento notablemente más rápido. Experiencia del usuario.
