menu_superior

MAGNITUDES PARA EXPRESAR LA CARGA DE TRABAJO DE UN S.I.

Foto por Danny Cornelissen (http://www.portpictures.nl)

La semana pasada estuve un par de días en Barcelona, trabajando para el Departament d’Ensenyament de la Generalitat de Catalunya. Había que realizar unas pruebas de rendimiento para una aplicación que saldría en pocos días a producción y querían hacer una simulación para asegurar la configuración que utilizarían en este “lanzamiento”. Mi función allí era asesorar en el proceso, ejecutar las pruebas y analizar los resultados para detectar anomalías o problemas que pudiera haber.

Hasta aquí todo normal, una aplicación web con integraciones con otros sistemas, distintos escenarios de carga y varias configuraciones para probar… Lo que sí me pareció confuso desde el principio era la forma de controlar la carga a la que sometíamos al sistema. Para el equipo de desarrollo la carga de trabajo se medía en usuarios virtuales, es decir, tantos usuarios virtuales usamos para atacar la aplicación tanta carga de trabajo. La idea de este post y del siguiente es explicar porque no es buena idea usar usuarios virtuales como medida de carga y cuales serían las magnitudes más adecuadas para conocer con precisión la carga a la que estamos sometiendo al sistema.

Los usuarios virtuales no sirven para expresar la carga de trabajo de un S.I.

Un usuario virtual es una medida de la capacidad de generación de carga que tenemos licenciada en HP-LoadRunner. Y ya. Punto. Todo lo demás es pura coincidencia: hay veces que son equiparables a un usuario real. Sí. Pero no siempre, ni siquiera “a menudo”. No, realmente no es una buena magnitud para explicar la carga que queremos inyectar a un sistema por que implica un sesgo congnitivo que provoca las siguientes distorsiones:

  1. Concurrencia. Que una prueba utilice 100 usuarios virtuales no nos da una idea de la concurrencia de esos usuarios, ya que no podemos saber cuantos están haciendo la misma operación simultaneamente. Necesitamos conocer la duración de la prueba, la cantidad de veces que han llevado a cabo una operación y si esta ejecución ha sido lineal o ha tenido picos… Es decir, sabremos a posteriori si el escenario es el que queríamos ejecutar y si no tendremos que repetir la prueba.
  2. Visualización de usuarios. Hablar de usuarios virtuales o reales, por muchas salvedades que se hagan, provoca que los responsables de la aplicación los “vean” delante del teclado. Esto desenfoca la información y condiciona la toma de decisiones ya que normalmente cada usuario virtual equivale a varios usuarios reales. Imaginemos que le decimos a los responsables de la aplicación (el product owner) que las pruebas certifican que 150 usuarios pueden operar en el sistema de manera concurrente y su plantilla es de 500 personas… La idea que estamos lanzando es que el sistema no está bien dimensionado.
  3. Multiplicación de usuarios virtuales. El think time. Los usuarios reales y los virtuales no tienen por que actuar a la misma velocidad. Cuando construimos un script, hay que tener en cuenta la velocidad de ejecución del mismo. Existe una variable, denominada think time que sirve para controlar esta velocidad de ejecución. El tiempo que ralentizamos un script puede no ser suficiente para igualar la velocidad de ejecución y la de los usuarios reales. Es decir, si un usuario necesita 60 segundos para rellenar los campos de la pantalla y enviar el formulario y el script lo hace en 12, cada usuario virtual podría equivaler a 5 usuarios reales.

Alguien podría pensar que no es tan mala idea y que se puede calcular la carga de trabajo partiendo desde el dato de la cantidad de usuarios virtuales empleados para ejecutar la prueba. Es cierto, pero incluso sabiendo hacerlo, tiene muchas contraindicaciones. En el próximo post voy a comentar otras magnitudes que son más inmediatas, más útiles y que facilitan la labor de planificar la prueba en función de la carga de trabajo del sistema.