Hay un tipo de caída especialmente doloroso: el que ocurre justo cuando el sitio recibe más gente que nunca. Salió la nota en el medio, arrancó la campaña, empezó el Hot Sale, y el servidor devuelve error mientras miles de personas intentan entrar. La ironía es que ese tráfico costó dinero y esfuerzo conseguirlo, y se pierde entero en los diez minutos que tarda todo en volver.
La buena noticia es que estos episodios son casi siempre evitables, y la preparación se hace con dos semanas de anticipación.
Entender por qué se cae un sitio
Un sitio no se cae porque "hay mucha gente" en abstracto. Se cae porque se agota un recurso concreto, y conviene saber cuál para atacar el correcto.
El más común es la cantidad de procesos simultáneos. Todo plan tiene un tope de cuántas peticiones puede procesar tu sitio a la vez. Cuando se llena, las siguientes esperan en fila, y cuando la fila se llena, el servidor devuelve 503. No es que el servidor esté roto: está diciendo "no doy abasto".
El segundo es la base de datos. Cada visita que no viene de caché dispara consultas. Con muchas visitas simultáneas y consultas mal optimizadas, la base se convierte en el cuello de botella y todo el sitio se arrastra.
El tercero, menos frecuente, es el ancho de banda o la CPU, típico de sitios con muchas imágenes pesadas o procesos complejos en cada carga.
Dos semanas antes: medir dónde estás parado
No se puede preparar lo que no se midió. Antes de tocar nada, averiguá dos números.
El primero es cuánto tarda tu página en responder sin caché. Se mide con cualquier herramienta de velocidad, mirando el tiempo hasta el primer byte. Si ya está en 800 milisegundos con tráfico normal, bajo carga va a ser mucho peor.
El segundo es cuántas visitas simultáneas aguanta. Existen herramientas de prueba de carga que simulan visitantes concurrentes y te muestran a partir de qué número empiezan los errores. Correr una prueba modesta, en un horario de bajo tráfico, te da una referencia real en vez de una intuición.
Con esos dos números sabés si tenés margen o si vas derecho al problema.
La caché: la medida que más rinde
Si tuvieras que hacer una sola cosa, sería esta. Una página sin caché obliga al servidor a ejecutar código y consultar la base en cada visita. La misma página cacheada se entrega como un archivo estático, y la diferencia de capacidad es de un orden de magnitud, no de un porcentaje.
Tres puntos a verificar. Primero, que la caché de página esté activa y realmente funcionando: probá en una ventana de incógnito y mirá si la respuesta trae la cabecera que indica que vino de caché. Segundo, que el tiempo de vencimiento sea razonable para el evento: durante un pico conviene que las páginas se guarden más tiempo del habitual. Tercero, y esto se olvida siempre, que las páginas que no se pueden cachear estén identificadas: carrito, cuenta y checkout tienen que quedar fuera, porque cachearlas provoca que alguien vea el carrito de otro.
Si tu hosting ofrece caché a nivel de servidor, usala en lugar de un plugin. Trabaja antes de que arranque PHP y rinde mucho más.
Una semana antes: podar lo que sobra
Este es el momento de sacar peso. Revisá los plugins activos y desactivá los que no son imprescindibles para el evento, especialmente los que corren en cada carga: relacionados, contadores, sliders, estadísticas propias.
Prestá atención especial a cualquier cosa que escriba en la base en cada visita. Los plugins de estadísticas internas son el ejemplo clásico: con tráfico normal no se notan, y con un pico multiplican las escrituras justo cuando la base está saturada. Durante el evento, medí con una herramienta externa.
Revisá también las imágenes de las páginas que van a recibir el tráfico. Convertirlas a un formato moderno y al tamaño correcto reduce la transferencia y acelera todo, especialmente para quien entra desde el celular con conexión mediocre.
Tres días antes: hablar con tu hosting
Esto casi nadie lo hace y es de lo más efectivo. Escribile a soporte contándoles que esperás un pico de tráfico tal día, en tal horario, de tal magnitud aproximada. Los buenos proveedores toman nota, y en algunos casos pueden ampliar temporalmente los límites de tu cuenta o al menos tener a alguien atento.
Es también el momento de evaluar si el plan alcanza. Si la prueba de carga mostró que empezás a fallar a las 200 visitas simultáneas y esperás 500, ninguna optimización va a cubrir esa diferencia. Subir de plan por un mes es más barato que perder la campaña.
El día del evento
Tres reglas simples. No publiques cambios ese día: ninguna actualización de plugins, ningún cambio de tema, nada. Si algo se rompe, se rompe en el peor momento posible.
Tené abierta una herramienta de monitoreo que te avise si el sitio deja de responder. Enterarte por un cliente que te escribe es enterarte tarde.
Y tené a mano una copia de seguridad reciente y verificada. No para el pico en sí, sino porque los eventos de mucho tráfico también atraen intentos de ataque.
Qué hacer si igual se cae
Si empiezan los errores 503, hay dos acciones que dan resultado inmediato. La primera es aumentar agresivamente el tiempo de vida de la caché, para que la mayor cantidad posible de visitas se sirvan sin tocar PHP. La segunda es desactivar temporalmente todo lo que no sea esencial para vender.
Lo que no sirve es reiniciar cosas al azar o desactivar la caché "para ver si mejora". Bajo carga, sacar la caché es la forma más rápida de empeorar todo.
Después: aprender del episodio
Terminado el evento, mirá los registros del servidor. Vas a poder ver a qué hora exacta empezaron los errores, cuántas peticiones por minuto estabas recibiendo y qué páginas concentraron la carga. Ese dato es lo que te permite dimensionar bien la próxima vez.
Y si la conclusión es que el plan quedó chico, tomalo como una buena noticia: significa que el proyecto creció. Ahí la conversación es con planes semi dedicados o un VPS, donde los recursos son tuyos y no compartís la máquina con otras cien cuentas. En BanaHosting ese salto se hace sin migrar de proveedor, que es una complicación menos en un momento donde ya tenés bastante de qué ocuparte.