Algunos sitios logran recargarse y recuperarse, pero en general, una vez que un sitio queda inactivo, generalmente requiere una intervención manual para que vuelva a estar en servicio.
La solución a este problema es realizar pruebas de carga en el sitio web. Este proceso no es realmente diferente a cualquier otro tipo de prueba de software.
Veamos los consejos:
1. Pruebas solo en producción.
Si está desarrollando servidores para sitios web dentro de una red propia, puede ser muy fácil asumir que todo está funcionando bien. En una red local, la latencia será casi inexistente, ningún enrutador externo tocará sus paquetes y las cosas a menudo pueden parecer que están funcionando sin problemas cuando en realidad la introducción de condiciones del mundo real puede causar problemas de inmediato.
2. Documentación.
Piense en su documentación como un mapa. Sin él, no tendrá idea de dónde buscar si surge un problema inexplicable, en este caso, en el sitio web.
Esta información no solo brinda un registro vital de lo que se logra en el sitio, sino que también sirve como punto de partida para cualquier investigación sobre por qué el sistema puede haber fallado.
3. Concentrarse en un sistema de conmutación de error.
Un sistema de conmutación por error efectivo para realizar las pruebas de carga es aquel que está diseñado para responder si un sistema principal activa uno o más umbrales de rendimiento. Los servidores de conmutación por error se pueden alinear en serie, por lo que si el sitio A falla, el sitio B puede captar el nuevo tráfico. Si el sitio B falla, el sitio C se conecta y así sucesivamente.
4. Simulacro.
La regla en cualquier proyecto es que la falla debe ocurrir lo antes y con el mayor volumen posible. El fracaso silencioso que llegue a ocurrir algún día es la perdición de cualquier proyecto que dependa de precisión, ingeniería compleja, etc.
La información que recopile de una falla programada dentro del sitio web, expondrá las debilidades del sistema, y una vez que sepa dónde es propenso a fallar, se pueden efectuar reparaciones para mitigar problemas futuros.
A decir verdad, el desarrollo de software se parece mucho a escribir un libro. Las pruebas, borradores y la edición a menudo toman más tiempo que escribir el trabajo en si en primer lugar.
