Durante una campaña o una hora punta, los archivos estáticos permanecen disponibles pero las páginas de WordPress esperan o devuelven errores 502/503. Todos los workers de PHP pueden estar ocupados. Aumentar el límite de trabajadores solo puede ayudar si la CPU, la memoria y la base de datos pueden admitir más solicitudes simultáneas.
Primero encuentre qué ocupa cada trabajador y por qué el tráfico llega a PHP.
Confirmar cola en lugar de una interrupción general
Correlacione el tiempo del incidente entre el servidor web, PHP-FPM y las métricas de hosting. Busque advertencias de procesos alcanzados, crecimiento de colas de escucha, tiempos de espera de puerta de enlace y respuestas PHP lentas.
Compare un archivo estático con una URL dinámica sin caché. Si la entrega estática es rápida mientras PHP espera, el grupo de aplicaciones es un fuerte sospechoso. Si ambos fallan, investigue la capacidad del servidor o de la red de manera más amplia.
Utilice marcas de tiempo que tengan en cuenta la zona horaria. Es posible que los registros de CDN, servidor y análisis no compartan la misma zona horaria.
Medir la simultaneidad y la duración de las solicitudes
La demanda de los trabajadores está impulsada aproximadamente por las solicitudes PHP simultáneas multiplicadas por el tiempo que cada una ocupa un proceso. Diez solicitudes rápidas pueden ser más fáciles que dos llamadas API externas lentas que se bloquean cada una durante segundos.
Revise los registros lentos o los seguimientos de aplicaciones para la ventana pico. Solicitudes de grupo por ruta: errores de página de inicio, admin-ajax.php, API REST, pago, cron y bots.
No registre cuerpos de solicitud completos ni datos de pago. Las rutas, las duraciones y el estado de respuesta suelen ser suficientes.
Verifique la tasa de aciertos de la caché al mismo tiempo
Una limpieza de caché de página completa durante un pico de tráfico puede enviar a todos los visitantes a PHP. También puede hacerlo una cookie o un parámetro de consulta que omita el caché.
Inspeccione las métricas de aciertos/errores de la caché y los eventos de invalidación. Confirme si una publicación de contenido, actualización de stock o implementación borró cachés amplios inmediatamente antes de que se formara la cola.
Proteja las rutas dinámicas de WooCommerce, pero mejore la capacidad de caché para páginas genuinamente públicas. Nunca almacene en caché el HTML de pago para reducir el uso de los trabajadores.
Busque llamadas externas lentas
SMTP, comprobaciones de licencias, fuentes remotas, servicios de divisas y API de seguimiento pueden bloquear a los workers de PHP mientras esperan otro servidor. Los seguimientos de aplicaciones o los registros lentos de PHP pueden revelar funciones de red en la pila.
Establezca tiempos de espera razonables y mueva el trabajo no esencial a un trabajo en segundo plano donde el plugin lo admita. No suprima una respuesta de pago requerida o una verificación de webhook.
Caché de datos remotos estables con vencimiento explícito y comportamiento de falla.
Inspeccionar trabajos cron y asincrónicos
El cron de WordPress, el Programador de acciones y las tareas de respaldo pueden iniciar muchas solicitudes PHP a la vez. Haga coincidir los registros de trabajos con la ventana de saturación.
Ejecute un trabajo pesado y recurrente fuera de las solicitudes de página activadas por visitantes cuando el hosting lo permita y evite ejecutores duplicados. Escalone las copias de seguridad, la regeneración de imágenes y las transmisiones lejos de los picos conocidos.
No elimines acciones pendientes de WooCommerce de forma indiscriminada. Pueden representar correos electrónicos, pagos, suscripciones o actualizaciones de acciones.
Evaluar los límites de los trabajadores con memoria y CPU
Cada proceso PHP consume memoria y los procesos concurrentes compiten por las conexiones de la CPU y la base de datos. Revise el pico de memoria real por trabajador y el espacio libre total del servidor.
Aumentar pm.max_children sin capacidad puede generar intercambios y hacer que cada solicitud sea más lenta. En el hosting administrado, el plan puede imponer el recuento de trabajadores; Las métricas del proveedor pueden mostrar límites de aciertos.
Reduzca la duración por solicitud y el tráfico PHP innecesario antes de comprar capacidad y luego dimensione el grupo a partir de la demanda medida.
Prepare un comportamiento pico elegante
Caliente las páginas públicas críticas después de purgas controladas, limite la velocidad de los endpoints abusivos y asegúrese de que la CDN pueda absorber el tráfico estático. Proteja el inicio de sesión y las búsquedas costosas sin bloquear a los clientes legítimos.
Utilice un mensaje de mantenimiento o de cola solo cuando sea necesario y evite los bucles de reintento que aumentan la carga. Supervise la tasa de errores, las colas y los resultados de pago exitosos durante el próximo pico.
Cuando se justifica una intervención urgente
Solicite una reparación urgente del rendimiento cuando los pedidos fallen, los registros de PHP-FPM muestren un agotamiento repetido del grupo o la ruta raíz no esté clara. Comparta primero los tiempos de incidentes, los registros desinfectados y las URL afectadas.
Una reparación responsable debería reducir el trabajo que retiene a los trabajadores, preservar el comportamiento dinámico del comercio electrónico y sólo entonces recomendar capacidad adicional basada en evidencia.