¿Por qué no funcionan las pruebas de carga?
"¿Por qué se ha caído tu página web? Debíais saber que iba a estar ocupado".
Se oye mucho, cuando un sitio web se cae en un momento crucial. Se hacen las mismas preguntas en las redes sociales, con el mismo tono acusador. "Debían saber que iba a haber mucho tráfico. ¿Por qué no le echaron unos cuantos gigas más?".
Para los usuarios decepcionados, parece obvio que la empresa debería haber tomado más medidas preventivas antes de un gran pico de tráfico, y que lo único que podría haber salido mal es una mala planificación.
Pero, ¿cuáles son esas medidas preventivas? ¿Pruebas de carga? ¿Un "servidor más grande"? ¿Más servidores quizás? ¿Qué tal una de esas nubes mágicas y escalables sin servidor?
A menudo, la primera vez que nos reunimos con los desarrolladores web de un equipo, están en una sesión de incorporación de CrowdHandler con el rabo entre las piernas. Sienten que han fracasado. Lo han hecho todo según las normas y el sitio web sigue sin funcionar, así que ahora, por falta de tiempo, tienen que pegarlo con cinta adhesiva en una sala de espera. Los primeros diez minutos de la reunión se dedican a sacar las excusas.
Lo hemos oído todo. Estás reconstruyendo la plataforma y el nuevo sitio no tendrá estos problemas. Has heredado una base de código que no puedes cambiar. Estás atascado en una versión antigua de Framework X, que es conocida por sus problemas de rendimiento. Podrías arreglar todos los problemas, por supuesto; es sólo una cuestión de tiempo.
La razón de la vergüenza es que la mayoría de los cuellos de botella -los problemas que impiden a los sitios web gestionar miles y miles de usuarios- se basan en el código, del que los desarrolladores se sienten responsables.
Estos cuellos de botella suelen estar en el backend: algo detrás del escaparate: un sistema que gestiona las entradas o las citas, o el procesamiento de tarjetas de crédito, por ejemplo. Pero con la misma frecuencia, los cuellos de botella están en el propio escaparate. En el código web. Código sobre el que los desarrolladores tienen pleno control.
Escuchar las excusas de los desarrolladores no nos hace sentir engreídos ni superiores. Lo que más sentimos es reconocimiento. Esta es la verdad: el código de nadie escala a la primera, y la mayor parte de lo que te han enseñado sobre cómo escribir código escalable es erróneo.
Te explicaré por qué no es culpa tuya dentro de un momento, pero antes quiero presentarte una nueva forma de pensar sobre la Sala de Espera.
Instalar CrowdHandler no es admitir el fracaso. De hecho, podría ser el primer paso para solucionar su problema de escalabilidad. En lugar de una tirita, me gustaría que pensaras en CrowdHandler como una herramienta de diagnóstico que apoyará tu trabajo y te ayudará a mejorar.
No es culpa tuya
Entonces, ¿por qué no es culpa de los desarrolladores cuando el sitio web no puede soportar el tráfico?
La razón por la que el código convencional está lleno de cuellos de botella relacionados con el código es que los desarrolladores web convencionales no suelen trabajar en sitios web increíblemente populares. Cuando los desarrolladores web se forman y aprenden, sus conocimientos sobre optimización y cómo escribir código de alto rendimiento suelen ser teóricos.
Aprender a escribir código escalable en teoría y luego ver a cien mil usuarios golpear tu sitio en la práctica me recuerda aquella cita de Mike Tyson: Todo el mundo tiene un plan hasta que le dan en la boca'. Ahora te han dado en la boca. Deberías estar orgulloso. La inmensa mayoría de los desarrolladores web nunca trabajan en nada lo suficientemente popular como para descubrir lo que se siente.
Así que a usted -y a su jefe- me gustaría decirles: es completamente normal que su sitio web no pueda escalar mágicamente para manejar cualquier nivel de tráfico. No esperes que lo haga.
¿Cuál es la respuesta?
Por supuesto, usted quiere hacer su sitio tan eficiente y escalable como sea posible. Sin embargo, muchas de las supuestas soluciones para la escalabilidad, para el tipo de números de los que estamos hablando aquí, en realidad no funcionarán.
Puedes centrarte en frameworks y lenguajes que teóricamente son más rápidos, pero la diferencia es mínima cuando se trata de dar servicio a miles o millones de usuarios.
¿Sabes qué es lo que marca la diferencia? La caché. No el tipo de caché de objetos precisa que desea hacer cerca del servidor con Memcached, pero ese borde sucio HTTP caché cerca del usuario que se siente como si estuviera fuera de su control. Esto realmente mejora el rendimiento, pero es difícil de hacer bien, y es difícil de adaptar a marcos y sistemas de gestión de contenidos que no lo tienen en cuenta.
Así que supongo que podrías empezar con pruebas de carga. Pero, de forma un tanto controvertida, no creo que las pruebas de carga rutinarias puedan ayudarte mucho. En mi experiencia, a menudo es una costosa pérdida de tiempo.
¿Por qué? Porque el comportamiento real del usuario es complicado. Puede que configure recorridos de usuario básicos para sus pruebas de carga que impliquen que los usuarios naveguen por una página, seleccionen un producto, lo añadan a un carrito y pasen por caja, pero eso no es lo que ocurre en el mundo real. Allí, los clientes van de un lado a otro, mirando todas las opciones, cambiando de opinión, haciendo largas pausas antes de recargar las páginas y abriendo cuatro pestañas en diferentes productos para comparar. Puede haber miles de estos complicados recorridos al mismo tiempo, cruzando las mismas filas de la base de datos de forma impredecible.
Así que puede ejecutar una serie de pruebas de carga en el entorno de ensayo que rompen el sitio web en dos millones de usuarios y declarar dos millones a ser el número mágico. Pero, ¿son realistas esos dos millones de recorridos de usuario? ¿Demuestran realmente dos millones de experiencias auténticas y utilizables en el entorno de producción? ¿O el sitio web en vivo se habría bloqueado mucho antes cuando los usuarios empezaron a comportarse de forma realista? (No importa el momento en que alguien decide ejecutar un informe de ventas intensivo durante la venta real... oh, ¿no estás probando para eso?).
No olvidemos que las pruebas de carga también requieren mucho tiempo. Incluso con un script de recorrido de usuario simplificado, tendrá que volver a ejecutar y volver a ejecutar las pruebas, corrigiendo los problemas de configuración hasta que funcione. Y entonces, cuando funcione, tendrá que ejecutarlo hasta que rompa el sitio web. Puede ser un ciclo interminable. Muchos de nuestros clientes simplemente no pueden conseguir que sus herramientas de pruebas de carga generen la cantidad de tráfico que esperan ver en el mundo real, o les resulta prohibitivamente caro hacerlo.
Por último: la naturaleza de las pruebas de carga que estamos describiendo es un gran proyecto. Conozco muchas empresas que realizan una gran prueba de carga una vez al año. Pero están introduciendo nuevo código en producción muchas veces por semana. Es totalmente posible que una línea de código en el lugar equivocado invalide todo el esfuerzo de la prueba de carga y cambie totalmente los números con los que se está trabajando. Usted está empujando el código en producción utilizando la integración continua ahora. Si sólo hubiera alguna manera de ejecutar una prueba de carga continua...
La prueba de carga continua
Me gustaría que considerara CrowdHandler como una alternativa mucho más productiva y asequible que las pruebas de carga tradicionales. ¿Por qué? Porque CrowdHandler proporciona información de rendimiento continua y real, basada en el sitio web que está protegiendo, y le permite trabajar de forma más eficiente e iterativa.
Durante una venta, su panel de control muestra cuánto tarda en cargarse cada página y resume el rendimiento general de la página. En tiempo real, la función de autoajuste de CrowdHandler analizará la velocidad de la página, hará un seguimiento del número de usuarios y encontrará la tasa óptima de nuevos usuarios que su sitio puede soportar.
En otras palabras, se trata de ejecutar una prueba de carga continua contra su entorno de producción, utilizando usuarios del mundo real y ajustando el resultado en tiempo real.
Pero, a diferencia de una prueba de carga clásica, tiene una válvula de seguridad incorporada: la propia sala de espera. Si las cifras son erróneas, lo peor que puede pasar no es que el sitio web esté muerto, sino que la cola se alargue.
Y luego, aunque la gente haga cola un poco más de lo que te gustaría, puedes observar y aprender del comportamiento real del sistema. Puede ver qué páginas son especialmente lentas, lo que le permite encontrar los cuellos de botella en su aplicación, mientras que el ajuste automático gestiona la cola y mantiene la experiencia del usuario positiva. Puede ver en qué partes del sitio tendrá que concentrarse en la optimización para la próxima vez observando los datos de una venta real.
Sin una sala de espera en el lugar, si su aplicación estaba sufriendo de un cuello de botella desconocido, es muy poco probable que usted sería capaz de diagnosticar o incluso observar, porque su sitio web estaría muerto, y usted estaría frenéticamente tratando de desplegar medidas de mitigación de emergencia. Incluso si pudiera recuperar los datos de diagnóstico más tarde, es poco probable que una emergencia de carga en espiral, agravada por un tráfico incontrolado, le ofrezca una imagen clara de la causa raíz.
Y por eso hablo de CrowdHandler como una parte esencial de su kit de herramientas, en lugar de un parche adhesivo. Al elegir nuestra sala de espera, no te estás rindiendo y aplicando una solución rápida: estás incorporando una herramienta de diagnóstico adicional que puede ayudarte a mantener la cabeza despejada y a realizar mejoras continuas en tu rendimiento, al tiempo que reduces los reproches en las redes sociales.
Así que si está considerando CrowdHandler, por favor, no venga a nosotros con el rabo entre las piernas. ¡Levante la cabeza! Eres un desarrollador web. Estás trabajando en proyectos muy populares y estás comprometido a hacer las cosas aún mejor. Lo estás haciendo todo bien.