Ir al contenido 
Un elevado número de visitantes genera picos de carga en segundos: si el PHP worker, la base de datos y la caché no funcionan, la llamada a la página termina en el Tiempo de espera de WordPress. Le mostraré por qué se atascan las peticiones, cómo puede identificar la causa y utilizar configuraciones y actualizaciones específicas para eliminar los tiempos de espera bajo carga, de forma permanente. performante.
Puntos centrales
- CausasPHP workers sobrecargados, base de datos lenta, falta de caché
- DiagnósticoRegistros del servidor, pruebas de carga, comprobaciones de plug-ins y análisis de consultas
- InmediatamenteAumentar los límites de PHP, cambiar WP-Cron, reparar .htaccess
- OptimizaciónCaché, caché de objetos, ajuste de imágenes y activos, CDN
- EscalaAlojamiento más sólido, más PHP workers, ajuste de los límites de conexión
Por qué una carga elevada provoca tiempos de espera
El aumento de consultas simultáneas consume primero el espacio libre. CPU, entonces la E/S y los bloqueos de la base de datos se bloquean y los tiempos de respuesta aumentan. A menudo veo PHP workers funcionando a pleno rendimiento mientras las nuevas peticiones se quedan colgadas en la cola y luego dan un error 504 o 502 - un clásico Tiempo de espera. El alojamiento compartido lo agrava porque compartes recursos con otros proyectos y los picos se acumulan. Aún más traicionero: consultas de base de datos no optimizadas en wp_options o entradas con revisiones que cuestan segundos. Combinado con la falta de caché de la página, al final no queda presupuesto de tiempo para el sitio.
502 vs. 504: Interpretar correctamente las imágenes de error
Diferencio los síntomas antes de disparar: A 502 Puerta de enlace incorrecta suele indicar un proceso backend PHP bloqueado o inalcanzable (reiniciar FPM, comprobar límites). A 504 Tiempo de espera del gateway agotado indica que el upstream (PHP-FPM) está respondiendo demasiado despacio - normalmente es el resultado de trabajadores bloqueados, consultas lentas o demasiado ajustadas tiempo_de_lectura-en el proxy. Si ambos errores se producen alternativamente, la atención se centra en la longitud de las colas y los límites de conexión: el proxy puede seguir aceptando nuevas conexiones, pero FPM ya no acepta trabajos o los rechaza por sobrellenado.
Encuentre la causa: Diagnóstico en minutos
Empiezo por los registros de errores y accesos, porque es donde reconozco los picos de Solicitudes y tiempos de ejecución largos inmediatamente. A continuación, compruebo la CPU, la RAM, la E/S y los procesos PHP activos: si los workers están al límite o si predominan las consultas lentas. A nivel de la aplicación, activo el registro de depuración para ver las acciones y los ganchos largos e identificar las consultas defectuosas. Plugins para aislarlo. A continuación, desactivo todas las extensiones y las activo individualmente hasta determinar el desencadenante. Por último, simulo la carga para ver cuándo empieza a fallar y si la caché y la caché de objetos surten efecto.
Medidas inmediatas que tienen un efecto notable
Primero aumento el tiempo de ejecución y la memoria para que correr Procesos no morir en tiempo de espera: en wp-config.php con set_time_limit(300); y por define('WP_MEMORY_LIMIT','512M');. Si se permite, me puse en .htaccess php_value tiempo_de_ejecución_máximo 300 y php_value limite_memoria 512M para saber más Tampón. Luego desactivo WP-Cron mediante define('DISABLE_WP_CRON', true); y configurar un cron sistema real para que las solicitudes de página no desencadenar cron se ejecuta. Hago que el diálogo permalink genere un .htaccess nuevo si el archivo está corrupto. Por último, vacío todas las cachés y compruebo en la ventana de incógnito si el TTFB se colapsa o permanece estable.
Configurar específicamente los tiempos de espera del servidor web y del proxy
Me aseguro de que la cadena de servidor web y PHP-FPM tiene suficientes ventanas de tiempo, pero no genera ningún bloque ocioso. Para NGINX ajusto fastcgi_read_timeout, fastcgi_connect_timeout y send_timeout moderadamente al alza (por ejemplo, 60-120 s), mientras que tiempo de espera de keepalive sigue siendo más bien corto para no saturar las franjas horarias. Detrás de un proxy inverso (equilibrador de carga) se encuentran proxy_read_timeout y proxy_connect_timeout ambos tienen que coincidir con el FPM y el presupuesto de la aplicación. En Apache limito Tiempo de espera de KeepAlive (2-5 s) y aumentar MaxRequestWorkers sólo si las reservas de RAM son suficientes para los procesos adicionales. La regla es: los tiempos de espera deben ser suficientemente grandes, pero la duración y el número de conexiones deben controlarse para que no se creen conexiones zombis.
Configurar PHP-FPM, procesos y límites correctamente
Los tiempos de espera suelen producirse porque hay muy pocos PHP workers en ejecución o porque están bloqueados durante demasiado tiempo - aquí ayudo a decidir PHP-FPM a través de pm=dinámico/sin demanda y límites razonables. Un valor inicial aproximado para pm.max_hijosRAM disponible para PHP dividido por el tamaño medio de los procesos, entonces deje 20-30% de reserva para que el servidor pueda respirar. pm.max_requests evita las fugas de memoria, y pm.process_idle_timeout reduce los costes de inactividad si la carga fluctúa. Yo activo estrictamente Opcache para que el intérprete no recompile constantemente y el TTFB se reduzca significativamente. Si quieres profundizar, puedes encontrar prácticas Configuración de PHP-FPM, que utilizo como base antes de escalar o adaptar el tema a NGINX/Apache.
Apache/NGINX/LiteSpeed: Modelos de trabajador y keep-alive
Elijo el modelo de trabajador que se ajuste al perfil de tráfico: Apache con mpm_evento escala mejor que prefork y armoniza con FPM. NGINX se beneficia de procesos_trabajadores (auto) y alta conexiones_trabajadores, para servir a muchos clientes simultáneos. LiteSpeed/LSAPI enlaza PHP eficientemente, pero requiere Max-Conns personalizados en el lado PHP. Keep-Alive Lo mantengo activo, pero breve: tiempos de espera cortos y limitados. keepalive_requests evitar que los clientes inactivos bloqueen las franjas horarias. Esto merece la pena en HTTP/2 y HTTP/3, ya que varios activos se ejecutan a través de una conexión y se reduce la sobrecarga.
Racionalice y agilice su base de datos
El freno más común se encuentra en el Base de datosrevisiones hinchadas, transitorios antiguos y una carga excesiva de autoload en wp_options. Regularmente ordeno, reduzco revisiones, borro transitorios caducados y mantengo autoload='yes' pequeño en general para que WordPress no cargue cientos de kilobytes al arrancar. Optimizo las tablas con la herramienta DB y compruebo si faltan Índices para condiciones WHERE frecuentes. En el caso de datos multimedia de gran tamaño, recurro a la descarga o a consultas de metadatos eficientes para evitar que los JOIN exploten. Si es necesario, también elevo paquete_máximo_permitido y utilizar una caché de objetos (Redis/Memcached), lo que reduce notablemente la carga en los accesos de lectura.
Parámetros MySQL/InnoDB y análisis de consultas lentas
Activo el Registros de consulta lentos temporal (pequeño tiempo_consulta_largo-por ejemplo, 0,2-0,5 s) para hacer visibles los valores atípicos. Para InnoDB I dimension innodb_buffer_pool_size (50-70% de la DB-RAM) para que los datos calientes se almacenen en la memoria. innodb_log_file_size y innodb_flush_log_at_trx_commit Ajusto dependiendo de los requisitos de consistencia. Un SSD/NVMetmpdir acelera grandes tipos, y creo que max_conexiones en equilibrio con el número de PHP workers y connection pooling para que la BD no tenga que thrashear. Importante: Evite las trampas de autocompromiso y las transacciones largas, ya que alargan los bloqueos y ralentizan cadenas de páginas enteras.
Caché y CDN: aligerar la carga de la aplicación
El almacenamiento en caché de páginas entrega HTML sin tocar PHP o la base de datos - esta es la mayor ventaja durante los picos de tráfico. Palanca. Configuro una caché de página completa con un TTL largo, diferencio entre usuarios registrados e invitados y activo „stale-while-revalidate“ para que las páginas sigan siendo rápidas incluso durante las reconstrucciones. Una caché de objetos acelera las Consultas, mientras que una CDN entrega activos estáticos cerca del usuario y reduce masivamente la carga de Origen. Convierto las imágenes a WebP, activo la carga perezosa y combino esto con HTTP/2 o HTTP/3 para que muchos archivos fluyan en paralelo. Esta guía de Caché de página completa, que siempre priorizo durante los picos de carga.
Estrategia de caché: claves, variantes y protección contra estampidas
Defino claves de caché tempranas y estables: ruta, host, cookies relevantes (las menos posibles) y tipo de dispositivo. Configuro deliberadamente las cookies que personalizan (por ejemplo, cesta de la compra, moneda) como Variar o los puenteo con caché fragmentada. Contra Cache Stampede ayuda a „stale-while-revalidate“, microcaching (1-10 s) en el servidor web y precalentamiento de rutas críticas antes de las campañas. Me ocupo de limpiar InvalidaciónBorrar específicamente cuando se publica el contenido en lugar de vaciar toda la caché. De este modo se mantienen altos los índices de aciertos y constantes los tiempos de respuesta, incluso a plena carga.
Comparación de alojamientos y actualizaciones razonables
En algún momento, se alcanza el punto en el que los límites del paquete surten efecto - entonces el sitio necesita más Recursos en lugar de afinar. Cuando las cosas se ponen realmente ajetreadas, dejo los entornos compartidos y me paso a ofertas gestionadas con CPU/RAM dedicadas o a un VPS con NGINX/LiteSpeed y almacenamiento NVMe. IOPS rápidas, suficientes PHP workers y el último PHP 8+ con Opcache. Para picos recurrentes, el autoescalado ayuda a escalar el trabajador y la base de datos sin intervención manual. El siguiente resumen muestra opciones comunes y para qué son adecuadas.
| Lugar | Proveedor/Tipo | Espesor del núcleo | Recomendado para |
|---|---|---|---|
| 1 | webhoster.de (Gestionado) | Autoescalado, SSD NVMe, CPU/RAM altas, WP gestionado | Alto tráfico, escalado |
| 2 | Alojamiento WP gestionado | Almacenamiento en caché integrado, PHP workers optimizados | Carga media |
| 3 | VPS con NGINX/LiteSpeed | IOPS elevadas, recursos dedicados | Sitios sofisticados |
Escalado, límites de conexión y PHP workers
El paralelismo se rompe si el servidor web, PHP-FPM o la base de datos son demasiado estrechos. Límites conjunto. I balance pm.max_hijos con el tamaño real del proceso, regular los keepalives del servidor web y comprobar los pools de conexión MySQL. Por cierto, demasiados trabajadores pueden agotar la RAM y atascar la E/S - por lo tanto, procedo paso a paso y mido. Si se producen errores 500 o 504 bajo carga, compruebo conjuntamente los límites de conexión, los tiempos de espera y la longitud de las colas. Una explicación compacta de las trampas de límite típicas se puede encontrar en este artículo sobre Límites de conexión, lo que a menudo me ahorra minutos a la hora de analizar la causa.
Almacenamiento eficiente en caché de WooCommerce y áreas dinámicas
El comercio electrónico supone un reto para la estrategia de caché: Almaceno en caché las páginas de categorías, las páginas de productos y el contenido del CMS, mientras que la cesta de la compra, el proceso de pago y „Mi cuenta“ se excluyen específicamente de la caché. Fragmentos de carro y banners personalizados mediante la recarga o fragmentación de pequeñas partes dinámicas a través de JavaScript. Cookies como las de moneda, país o sesión sólo acaban en el Variar, cuando es inevitable; de lo contrario, destruyen el índice de aciertos. Caliento las acciones planificadas (por ejemplo, las ventas) para que ninguna caché fría se caliente al principio. Limito los puntos finales de administración Ajax y REST agrupando las consultas, almacenando en caché los resultados y limitando el sondeo.
Pruebas de carga, supervisión y alerta
No me baso en los sentimientos, pruebo los efectos con Medidas. Antes de las campañas, simulo oleadas de visitantes, aumento gradualmente la concurrencia y compruebo en qué carga aumentan el TTFB y la tasa de errores. Las herramientas APM me muestran las transacciones, las consultas y las llamadas externas más lentas: aquí es exactamente donde aplico el efecto palanca. Las alertas sobre CPU, RAM, tasa 5xx y tiempos de respuesta me avisan con antelación para que pueda estar preparado antes de que se produzca el verdadero problema. Fallo reaccionar. A continuación, repito la prueba con la caché activada para asegurarme de que las optimizaciones funcionan a plena carga.
Servicios externos y peticiones HTTP seguros
Muchos tiempos de espera provienen del bloqueo de llamadas HTTP en temas/plugins. Establezco ventanas de tiempo ajustadas para wp_remote_get()/wp_remote_post() (tiempos de espera de conexión/lectura), incorporo fallbacks y muevo las costosas sincronizaciones a tareas en segundo plano. Compruebo la resolución DNS y el protocolo SSL por separado: los resolvers defectuosos o las cadenas de certificados ralentizan notablemente las cosas. Almaceno localmente en caché los resultados recurrentes para que los fallos de las API externas no afecten al sitio. Principio: La E/S externa nunca debe dominar el tiempo de ejecución de la petición.
Seguridad, tráfico de bots y reglas WAF
Protejo la aplicación contra el tráfico inútil: Límites de velocidad en los puntos finales de inicio de sesión, XML-RPC y búsqueda, reglas estrictas contra scrapers y bots maliciosos, así como un acelerador para crawlers agresivos. 429/503 con Reintentar después de ayudan a mantener la capacidad libre para los usuarios reales. Un WAF upstream clasifica los picos de la capa 7 y bloquea los vectores de ataque conocidos antes de que afecten a PHP/DB. Para los medios, activo el almacenamiento en caché sensible (ETag/Last-Modified) para que las llamadas repetidas apenas generen costes de servidor.
Límites del sistema y ajuste del SO
Si las conexiones se rechazan repentinamente bajo carga, miro los parámetros del sistema operativo: fs.archivo-max y descriptores abiertos para servidor web/DB, net.core.somaxconn y net.ipv4.ip_local_port_range para muchas tomas simultáneas. Una demasiado pequeña retraso o agresivo tcp_fin_timeout crea cuellos de botella. Muevo los registros que se cuelgan al disco a soportes de datos rápidos o los roturo con fuerza para que la E/S no ralentice la aplicación.
Caché de objetos: uso correcto de Redis/Memcached
Elijo Redis por la persistencia y características como las directrices de flujo. memoria máxima para que las teclas de acceso rápido no se desplacen, y establece una política de desalojo adecuada (por ejemplo, allkeys-lru). Serializadores como igbinary ahorran RAM, TTLs cortos en transitorios volátiles reducen el churn. Importante: La capa de caché de objetos debe aliviar a la BD - si el ratio de aciertos sigue siendo bajo, analizo la distribución de claves e igualo las rutas de código hasta que aumenten los aciertos.
Elimine rápidamente las fuentes habituales de error
Muchos tiempos de espera son causados por unos pocos desencadenantes - Yo compruebo primero Cron, Heartbeat y búsqueda. Cambio WP-Cron por el cron del sistema, estrangulo fuertemente la API Heartbeat y sustituyo las costosas listas backend por caché del lado del servidor. Los plugins problemáticos son eliminados o sustituidos por alternativas más ligeras, especialmente si causan errores externos cada vez que se llama a una página. APIs contacto. En .htaccess, elimino los bucles de redirección duplicados y corrijo los gestores de PHP incorrectos que duplican procesos. Ralentizo bots y scrapers con límites de velocidad y un CDN upstream para que los usuarios reales no tengan que esperar.
Resumen para una aplicación rápida
Remedio una inminente Tiempo de espera en un orden fijo: medir la causa, aumentar los límites, activar la caché, racionalizar la base de datos, aumentar el alojamiento. Una estrategia clara de trabajadores y caché es crucial para que las peticiones no compitan por los recursos. Con una caché de página completa limpia, una caché de objetos y activos WebP, la carga del servidor se reduce inmediatamente, a menudo muchas veces. Si esto no es suficiente, más CPU/RAM, un almacenamiento NVMe más rápido y unos parámetros PHP FPM bien configurados proporcionarán la necesaria Reserva. Las pruebas de carga y la supervisión cierran el círculo, porque sólo las mediciones repetidas garantizan el rendimiento con tráfico real.
