Una de las principales trampas de la creación de chatbots es subestimar la importancia del rendimiento. La interfaz de usuario de un chatbot suele ser muy simple, por lo que es fácil olvidar la complejidad detrás de estos asistentes virtuales. Un chatbot lento puede ser aceptado para proyectos domésticos, pero una empresa no puede descuidarlo. El mal desempeño es un serio asesino de UX.
Las pruebas de rendimiento son la clave para garantizar que tu chatbot es capaz de responder bajo una carga alta. El peor de los casos es quizás un chatbot que no responde en absoluto, porque no pudo recuperarse después de una carga alta causada por clientes o algún ataque informático.
Tabla de contenidos
Pruebas de estrés
Para recopilar algunos conocimientos básicos sobre el rendimiento de tu chatbot, te sugerimos comenzar con una prueba de estrés. Las pruebas de estrés básicamente significan que estamos comenzando con una pequeña cantidad de usuarios paralelos que aumenta gradualmente durante la ejecución. Después de unos minutos dará respuesta a dos preguntas fundamentales:
- Primero, el resultado principal es cuántos usuarios paralelos pueden ser atendidos sin ralentizar el sistema. Determinar cuáles son las partes lentas requiere, por supuesto, la interacción humana.
- En segundo lugar, pero no menos importante, se pueden detectar errores de salida. Por lo general, es el primer escenario cercano a la producción para un chatbot que experimenta un gran volumen de interacciones.
Veamos algunos ejemplos más de la vida real…
Primera prueba de esfuerzo
De forma predeterminada, todos los usuarios paralelos mantienen una conversación muy sencilla con el bot, por ejemplo, solo dicen «hola». Esperan una respuesta y repiten la conversación hasta que se llega al final de la prueba. Se acepta cualquier respuesta proveniente del chatbot. Entonces, si el chatbot responde a veces con «Hola usuario», a veces con «No entiendo», no tiene ningún impacto en los resultados de rendimiento. El objetivo principal aquí es obtener una respuesta, mientras que un código de error http o la falta de respuesta se interpreta como un error, por supuesto.
Para iniciar una prueba de esfuerzo, tenemos que seleccionar la pestaña «Pruebas de rendimiento» en nuestro Proyecto de prueba y elegir Prueba de esfuerzo allí.
La duración puede ser de 1 minuto. En términos de usuarios paralelos, usemos 5 para comenzar, 1000 para finalizar. (Puedes poner 1000 allí editando el campo directamente).
«¿Porcentaje requerido de usuarios exitosos?» puede ser del 0% porque no queremos detener la prueba por respuestas fallidas (por el momento).
Tengo dos objetivos con esta configuración; obtener una primera impresión sobre el número máximo de usuarios paralelos que el chatbot puede atender y descubrir cómo el chatbot se rompe con una carga extrema. En producción, tu chatbot podría tener mucha más carga de la esperada, por lo que debes probarlo.
El primer gráfico de los resultados de la prueba de esfuerzo muestra que hubo errores.
Vemos que el bot puede manejar fácilmente a 5 usuarios paralelos. Pero en el siguiente paso, cuando la cantidad de usuarios paralelos se incrementó a más de 200, el chatbot ya comenzó a fallar.
Para obtener más información sobre los problemas, puedes descargar un informe detallado.
Este informe contiene todos los errores detectados por Botium Box. Los tipos de fallas son:
- Tiempo de espera (el chatbot no responde en absoluto o es demasiado lento)
- Respuesta no válida (límite de API alcanzado, servidor inactivo, credenciales no válidas)
- Respuesta con contenido inesperado (Enviamos «hola» y esperamos «¡Hola!», Pero el chatbot responde con «¡Lo siento, se detectó un error, vuelve más tarde!»)
En mi caso, solo hay un tipo de error en el informe:
2168 / Línea 6: error al esperar el bot – El bot no respondió en 10000ms
Después de 10s, Botium Box ha dejado de esperar la respuesta. El tiempo de respuesta del chatbot superó el límite o no respondió en absoluto. Disminuir la velocidad es común en cargas extremas, pero no recibir respuesta es más crítico, eso no podemos ignorar.
Al revisar la Tabla de tiempos de respuesta en los resultados de nuestra prueba de esfuerzo, noto que el chatbot es demasiado lento. El tiempo de respuesta aumenta hasta que llega a los 10 segundos y la mayoría de las respuestas fallan. El siguiente paso ahora es verificar las métricas / registros del lado del chatbot o aumentar el tiempo de espera en Botium Box. En aras de la simplicidad, creo que mi impresión es correcta.
La primera prueba de esfuerzo me demostró que el número máximo de usuarios paralelos es de 200 y con cargas pesadas el chatbot no se romperá, sino que se ralentizará significativamente.
Segunda prueba de esfuerzo
Nuestra primera prueba de esfuerzo tuvo parámetros muy amplios. Tenía dos objetivos allí, obtener algunos resultados sin procesar sobre el número máximo de usuarios paralelos y verificar lo que sucede con cargas extremas. Con la segunda prueba de esfuerzo, quiero refinar el número máximo de usuarios paralelos.
Establecí la duración del paso de prueba en 2 segundos, lo que significa que cada dos segundos Botium Box aumentará el número de usuarios paralelos. Los usuarios mínimos a 150 y el número de usuarios máximos a 300. Con base en estos parámetros, Botium Box agregará cada 2 segundos 14 nuevos usuarios paralelos hasta que termine con 300 después de doce pasos.
Podemos establecer el «Porcentaje requerido de usuarios exitosos» en 95%. Nuestro objetivo ahora no es ir más allá del límite del chatbot, sino sobre el uso normal. Ya espero que la prueba falle debido a demasiados tiempos de espera. La pregunta es cuándo fallará (en qué número de usuarios paralelos).
Una vez finalizada la prueba, veo que falló como se esperaba:
Para estar seguro, verifico el informe Convos fallidos. Hay los mismos errores de tiempo de espera que tuvimos en la primera prueba y como esperaba. Eso es bueno.
El siguiente paso es verificar los gráficos de los resultados de la prueba de esfuerzo:
En el primer paso (150 usuarios paralelos) no hay errores (primer gráfico) y el tiempo medio de respuesta es de 5 s (segundo gráfico). El segundo paso (150 + 14 usuarios en paralelo) tiene el mismo aspecto. Y ahí ya encontré el límite de mi chatbot. No quiero fallas (respuestas superiores a 10 s) o tiempos de respuesta promedio superiores a 5 s.
El tercer paso es muy interesante. El tiempo medio de respuesta está aumentando. El número de usuarios no cambia en un paso de prueba, esperamos un tiempo de respuesta lineal como antes. Y revisando el primer gráfico vemos que hubo algunos errores.
En el último paso podemos ver la fase de desmontaje de la prueba en el gráfico 3. Los usuarios emulados no iniciaron ninguna conversación nueva, solo terminaron la actual.
Regreso al tercer paso. El chatbot parece estar sobrecargado al recibir más solicitudes de las que puede procesar. Otro hallazgo es que en la fase de desmontaje el tiempo de respuesta no se recupera. Probablemente porque el gráfico de tiempos de respuesta se redujo a 10 segundos debido al tiempo de espera utilizado por Botium Box. Supongo que hay un retroceso en los tiempos de respuesta, pero aún está por encima de los 10, por lo que no lo vemos.
Si la sobrecarga no es la causa, entonces tal vez algo se aspire allí (pérdida de memoria). Pero estoy bastante seguro de que está sobrecargado porque es demasiado progresivo para ser otra cosa. Lo demostraré en mi próximo artículo.
Resumen
En base a las dos pruebas realizadas, he determinado los límites de mi chatbot y sé cómo se comporta con cargas extremas. Basándome en esos KPI, puedo decidir las próximas acciones. Dependiendo de los requisitos de mi negocio y la arquitectura del chatbot, hay muchas opciones. Corregir errores existentes, hacer un escalado horizontal / vertical o aplicar cambios de código / arquitectura necesarios, por nombrar algunos.
Lo siguiente
Usar solo Stress Testing puede ser suficiente si tu chatbot se basa en un servicio externo. En casos más complejos, si posees la arquitectura del chatbot al menos parcialmente, se recomienda encarecidamente profundizar. En mi próximo artículo, cubriré las fugas (de memoria), los límites de API, el ataque Ddos y la supervisión del rendimiento.