Preparar una aplicación PHP para picos de tráfico no consiste en multiplicar el número habitual de visitas por un factor arbitrario. La capacidad necesaria depende de cuántas solicitudes coinciden, cuánto tarda cada una y qué trabajo ejecutan: una página cacheada y una operación que consulta varios servicios externos no consumen los mismos recursos.
El objetivo operativo es conocer qué componente limita el servicio bajo una carga representativa, cuánto margen existe y qué hacer cuando ese margen se agota. Las pruebas aportan evidencia para tomar decisiones; no garantizan una capacidad universal, porque el resultado depende del código, la infraestructura, los datos y el patrón real de uso.
Estima la carga por concurrencia y por tipo de operación
El volumen diario o mensual es insuficiente para dimensionar. Una aplicación puede recibir muchas visitas repartidas durante horas y funcionar con holgura, o concentrar solicitudes en pocos minutos y saturarse. Para aproximar la presión, observa la tasa de llegada, la duración de las peticiones y la proporción de operaciones concurrentes.
Como orientación, si aumenta la duración mientras se mantiene la tasa de llegada, más solicitudes permanecen activas al mismo tiempo. Por eso una dependencia lenta puede elevar la concurrencia aunque el tráfico entrante no cambie. El tráfico también puede ser desigual: una campaña puede disparar páginas de producto y búsquedas, mientras que un cierre de periodo concentra autenticaciones, exportaciones o escrituras.
Empieza por identificar las rutas y operaciones que afectan a los objetivos de negocio. Incluye, por ejemplo, navegación pública, búsqueda, inicio de sesión, creación de pedidos y tareas administrativas relevantes. Distingue lecturas de escrituras, peticiones cacheables de no cacheables y solicitudes síncronas de trabajos que podrían procesarse en una cola. No uses el promedio global para ocultar una ruta lenta o crítica.
Construye una prueba representativa y segura
Define uno o más escenarios a partir de la telemetría disponible, los registros de acceso y el calendario de eventos conocidos. Documenta qué proporción de solicitudes corresponde a cada operación, cómo varía la tasa de llegada y cuánto dura cada fase. Conviene probar una carga sostenida y un aumento rápido, ya que revelan comportamientos distintos: agotamiento progresivo de recursos frente a una reacción brusca ante un pico.
La prueba debe ejecutarse en un entorno que represente la configuración de producción lo suficiente para que sus resultados sean útiles. Revisa diferencias en número de procesos, límites de conexión, cachés, tamaño de datos y dependencias. Si una prueba se ejecuta en una máquina aislada con tablas pequeñas, no demuestra cómo responderá producción. Evita generar carga contra usuarios reales sin un plan y autorización explícitos.
Protege los datos desde el diseño del escenario. Usa datos sintéticos o anonimizados, credenciales específicas y permisos mínimos; no copies datos personales a herramientas de carga sin una base y controles adecuados. Evita que las pruebas envíen correos, cobren pagos o creen efectos irreversibles. Para operaciones externas, usa entornos de prueba o sustitutos controlados, teniendo presente que un sustituto no reproduce necesariamente la latencia ni los límites del servicio real.
Mide latencia, errores y saturación al mismo tiempo
Registra la latencia por ruta y observa percentiles, como p50, p95 y p99. El promedio puede permanecer estable mientras una parte de las solicitudes se vuelve muy lenta; los percentiles muestran mejor esa cola. Mide también tasa de errores, tiempos de espera y solicitudes completadas por unidad de tiempo. Una prueba que produce muchas solicitudes pero también errores no acredita capacidad útil.
Relaciona esas medidas con recursos y colas. En PHP, observa la ocupación y la cola de los procesos que atienden peticiones, además de CPU, memoria y reinicios. Si utilizas PHP-FPM, revisa la configuración y las métricas de sus procesos y del servidor web; el nombre del indicador disponible depende de la instrumentación. En la base de datos, mide conexiones activas, espera para obtener conexión, consultas lentas, bloqueos y uso de CPU o disco. Observa asimismo cachés, colas y dependencias externas.
Establece umbrales ligados a la experiencia y a las operaciones, no sólo al uso de CPU. Por ejemplo, una ruta de compra puede requerir una latencia y una tasa de error máximas acordadas, mientras que una exportación no crítica admite espera o procesamiento asíncrono. Comprueba que los relojes y ventanas de observación sean comparables y que puedas asociar un aumento de latencia con el componente que se saturó.
Localiza el primer cuello de botella antes de escalar
Busca la primera señal que empeora al aumentar gradualmente la carga. Si crece la cola de procesos web y la CPU de PHP permanece alta, puede haber trabajo costoso por petición o falta de procesos disponibles. Si los procesos esperan conexiones, pero la base de datos mantiene capacidad, revisa el límite del pool o la configuración de conexiones. Si la base de datos muestra consultas lentas, bloqueos o saturación, añadir procesos PHP puede aumentar la presión y empeorar el problema.
Las dependencias externas también pueden retener procesos. Revisa tiempos de conexión y respuesta, límites de tasa y comportamiento ante errores. Un tiempo de espera demasiado largo mantiene recursos ocupados; reintentar sin límite puede multiplicar la carga. Define tiempos de espera acotados y una política de reintentos selectiva, con espera progresiva cuando proceda, y evita repetir automáticamente operaciones no idempotentes sin protección.
Distingue falta de capacidad de ineficiencia. Una consulta que recorre demasiadas filas, llamadas repetidas al mismo servicio o cálculos redundantes seguirán siendo costosos al añadir servidores. Perfila rutas representativas y reduce trabajo por solicitud: optimiza consultas e índices con evidencia, limita resultados, elimina llamadas innecesarias y aprovecha caché cuando la consistencia y la privacidad lo permitan. Después repite la prueba para verificar que la mejora se sostiene bajo carga.
Intervén en orden y planifica degradaciones controladas
Primero reduce el coste del trabajo por petición y corrige las consultas o dependencias que actúan como límite. Después revisa los límites de concurrencia, los procesos web y los pools de conexiones. Aumentar procesos puede mejorar el paralelismo hasta que CPU, memoria o base de datos se saturen; configurar más conexiones de las que la base de datos puede servir sólo traslada la cola. Cambia una variable cada vez y vuelve a medir.
El escalado vertical —más recursos en una instancia— puede ser una intervención sencilla si el componente admite crecer y no hay un límite estructural. El horizontal —más instancias— requiere que el despliegue, las sesiones, los archivos, las tareas y la base de datos soporten esa distribución. Verifica balanceo, almacenamiento compartido o externo cuando corresponda, salud de instancias y límites comunes, como conexiones a la base. Ninguna opción corrige por sí sola una consulta ineficiente.
Define qué preservar cuando la capacidad escasea. Prioriza autenticación, operaciones esenciales o confirmaciones de transacción según el producto; aplaza informes, limita búsquedas costosas o desactiva temporalmente funciones prescindibles. Usa colas para trabajo que pueda completarse después y comunica el estado al usuario. Aplica límites de tasa o respuestas de sobrecarga de forma explícita, con mecanismos de reintento prudentes. Una degradación controlada debe evitar perder operaciones confirmadas y ofrecer una alternativa comprensible, no devolver éxito ficticio.
Para convertir las pruebas en una decisión operativa, conserva un registro con escenario, configuración, resultados por ruta, primer límite observado, cambios realizados y criterio de aceptación. Repite la prueba tras modificar código, infraestructura, datos o dependencias relevantes. Antes de un pico previsto, confirma alertas, capacidad disponible, procedimientos de reversión y responsables de decisión.
Lista de comprobación antes de un pico
- Escenario: refleja rutas, proporciones, ritmo y duración plausibles; incluye una subida rápida y una carga sostenida.
- Seguridad: emplea datos y credenciales adecuados, evita efectos reales no deseados y controla el destino de la prueba.
- Observabilidad: correlaciona latencia p95/p99, errores y throughput con procesos PHP, base de datos, caché y dependencias.
- Diagnóstico: identifica el primer límite y confirma si se debe a saturación, consultas, concurrencia o esperas externas.
- Cambio: modifica una causa cada vez, compara resultados y comprueba que no traslada la saturación a otra capa.
- Resiliencia: define límites, prioridades, degradaciones, comunicación y recuperación sin perder operaciones confirmadas.
- Repetición: fija criterios de aceptación y vuelve a probar después de cambios importantes y antes de eventos previsibles.
Dimensionar con rigor significa conocer la respuesta de la aplicación ante escenarios concretos y decidir con margen, no perseguir una cifra abstracta de usuarios. Las mediciones hacen visible dónde invertir: optimización, ajuste de concurrencia, capacidad adicional o una política de degradación que mantenga útiles las funciones esenciales.
