El mundo de los negocios en línea está repleto de historias de sitios web que lograron obtener una gran cantidad de tráfico y luego no pudieron manejar la carga.
Algunos sitios se recuperan, pero en general, una vez que un sitio está inactivo, generalmente requiere una intervención manual para que vuelva a funcionar. Esto puede costarle mucho negocio a una empresa, ya que las fallas en el sitio a menudo ocurren sin previo aviso y en momentos del día y de la semana en los que no hay técnicos calificados disponibles para restaurar el servicio.
La solución a este problema es realizar una prueba de carga en su sitio. Este proceso no es realmente diferente a cualquier otro tipo de prueba de software. Simplemente necesita operar el sitio en circunstancias diseñadas para simular las condiciones del mundo real lo más cerca posible.
A continuación, se ofrecen algunos consejos para asegurarse de que su proceso de prueba sea lo más eficaz posible.
1. Simule al menos una falla
La regla en cualquier proyecto de ingeniería es que la falla debe ocurrir lo antes y con el mayor volumen posible. El fracaso silencioso que ocurre algún día es la perdición de cualquier proyecto que dependa de la precisión, la tecnología o la ingeniería compleja.
La información que recopile de una falla expondrá las debilidades de su sistema. Una vez que sepa dónde es propenso a fallar el sistema, puede efectuar reparaciones de manera inteligente y mitigar problemas futuros.
La simulación de fallas puede proporcionar muchos tipos diferentes de métricas. Cada uno le dará una idea de los límites de su hardware y configuración. Cuanto más se pueda probar, más podrá fortalecer su sistema.
Para fortalecer un sistema y ejecutar la cantidad adecuada de pruebas, es bueno usar una herramienta que pueda simular una gran cantidad de usuarios como LoadView.
2. Concéntrese en su conmutación por error
Un sistema de conmutación por error 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.
En el ejemplo anterior, si la cantidad de solicitudes a un dominio o instancia de software en particular alcanza una cierta proporción de su límite, todas las solicitudes nuevas se pueden enrutar al sitio B. Es de vital importancia que se asegure de todos estos umbrales y su enrutamiento las configuraciones funcionan. Además, debe asegurarse de que funcionen incluso si el sitio y todas sus conmutaciones por error están bajo carga máxima.
3. Prueba solo en producción
Si está desarrollando servidores web dentro de su propia red, 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, a menudo, las cosas pueden parecer que están funcionando sin problemas cuando en realidad la introducción de condiciones del mundo real puede causar problemas de inmediato.
La calidad de sus servidores web también es importante. Por ejemplo, si está utilizando alojamiento empresarial de baja calidad para alojar su sitio, es posible que sus servidores tengan un alto grado de latencia, según Compañero de alojamiento web.
Un problema común que surge cuando una plataforma de prueba se mueve «al aire libre», por así decirlo, es que todo el software de prevención de fallas se activa al mismo tiempo porque interpreta la desaceleración de la red como un evento de alta carga. De repente, toda la red está compitiendo por la atención y provocando el tipo de interrupción que se suponía que debían evitar esos sistemas.
Configurar un entorno de prueba interno está bien, pero para obtener los datos correctos en las condiciones adecuadas, debe poner su avión en el aire. Si falla, al menos estará al tanto del problema con mucha anticipación.
4. Empiece por el metal
Como cualquier proyecto de software, un proceso de prueba de carga debe estar operativo en cada fase de integración. Esto significa que solo se puede ejecutar el software básico durante su primera prueba. Una vez que haya garantizado que su sistema base está funcionando, puede agregar complementos, complementos, filtros, etc. Cada uno debe aislarse y probarse por sí solo.
La razón por la que esto es tan importante es porque el software integrado tiene que degradarse con gracia. Si uno de esos complementos falla, no puede derribar todo el sistema. El sistema base tiene que ser sólido para que pueda seguir funcionando incluso si sus funciones auxiliares no funcionan.
Naturalmente, sus mecanismos de conmutación por error deberían activarse ante cualquier tipo de interrupción del software. La forma más sencilla de configurar esto es crear un mecanismo de sondeo para que el sistema base pueda hacer ping regularmente a los sistemas auxiliares para asegurarse de que estén activos.
5. Documentación
Sin excepción, la parte más importante de cualquier régimen de pruebas es documentar sus resultados. Esta información no solo le brinda un registro vital de lo que ha logrado, sino que también sirve como punto de partida para cualquier investigación sobre por qué el sistema puede haber fallado o desencadenado una conmutación por error. Piense en su documentación como un mapa. Sin él, no tendrá idea de dónde buscar si surge un problema inexplicable.
Bono: consejos para hacer que su sitio web móvil se cargue más rápido
La velocidad de carga es aún más crucial cuando se trata de la versión móvil de su sitio web.
Los usuarios de dispositivos móviles suelen estar en movimiento todo el tiempo y tendrían muy poca paciencia con los sitios móviles que tardan una eternidad en cargarse. Entonces, si desea mantener la atención de los usuarios de dispositivos móviles el tiempo suficiente para generar clientes potenciales o generar conversiones, la velocidad de carga de su sitio web móvil debe subir de nivel.
Estas son las mejores formas de hacer que su sitio web móvil se cargue más rápido en 2019.
A decir verdad, el desarrollo de software se parece mucho a la escritura de ficción. Las pruebas y la edición suelen llevar más tiempo que escribir el trabajo en primer lugar.
Sin embargo, el software no probado que conduce a fallas y pérdida de negocios es un riesgo demasiado grande para asumir con sus clientes y clientes ganados con tanto esfuerzo.