10/03/2022

La importancia de la Capacidad de Procesamiento en las Pruebas de Performance

COMPARTIR EN:

  • Linkedin Logo
  • Twitter Logo
  • Facebook Logo
  • Mail Logo

Los testers de software aplican varias técnicas para comprobar la calidad de las aplicaciones. Las Pruebas de Performance son una de las medidas más decisivas cuando el equipo está probando la rapidez, los tiempos de respuesta, la escalabilidad, la confiabilidad, y otros aspectos del software.

En este artículo, vamos a discutir los aspectos principales de la capacidad de procesamiento (“throughput” en inglés) en las Pruebas de Performance.

Los fundamentos de la capacidad de procesamiento en las Pruebas de Performance

Antes de comenzar con los detalles, repasemos algunos de los fundamentos de las Pruebas de Performance.

¿Qué son las Pruebas de Performance?

Las Pruebas de Performance son importantes porque: 

Más allá de los problemas de lógica o funcionales, las aplicaciones también tienen problemas de red que afectan su confiabilidad.
Los clientes se frustran rápidamente cuando la experiencia de accesibilidad de su aplicación no es buena.
La rapidez y el rendimiento de una aplicación cambia según la región en la que se está utilizando. Por ende, es importante evaluar el rendimiento de una aplicación a diferentes velocidades y con distintas redes.
Un sistema puede funcionar correctamente con un número específico de usuarios, pero puede empezar a funcionar de forma distinta cuando la cantidad de usuarios sobrepasa ese límite. Por ello, resulta necesario evaluar las Pruebas de Performance bajo condiciones específicas.

¿Cuándo debería empezarse con Pruebas de Rendimiento?

Puedes comenzar con las Pruebas de Performance tan pronto como sea posible dentro de la etapa de desarrollo de tu aplicación de software. De esta forma, podrás optimizar tu servidor web y prevenir costos para el negocio en etapas posteriores.

Si se descubren problemas de performance luego de lanzar una aplicación, serán necesarias muchas más horas de trabajo para corregir los problemas. Por este motivo, puede volverse muy caro.

Tan pronto como las páginas web básicas de la aplicación funcionen, el equipo de control de calidad debe comenzar con las pruebas de carga iniciales. Desde ese momento en adelante, deberían ejecutar Pruebas de Performance de forma regular para cada versión.

Hay distintas herramientas y criterios para realizar Pruebas de Performance sobre las aplicaciones. Aquí hablaremos sobre una medida muy importante: la capacidad de procesamiento.

¿Qué es la Capacidad de Procesamiento en las Pruebas de Performance?

Cada aplicación de software o página web tiene muchos usuarios que ejecutan distintas solicitudes. Los testers deben asegurarse de que la aplicación puede hacer frente a las solicitudes antes de salir a producción.

Hay algunos aspectos básicos de Pruebas de Performance que se deben medir durante el proceso. La capacidad de procesamiento es uno de ellos. Aprendamos primero qué es la capacidad de procesamiento en las Pruebas de Performance.

La capacidad de procesamiento es una métrica clave que indica la cantidad de solicitudes que una aplicación de software puede manejar en un tiempo específico (segundo, minuto u hora).

Antes de comenzar la prueba, debemos establecer un objetivo realista sobre la capacidad de procesamiento para tener resultados más precisos y confiables.

Los siguientes son algunos aspectos importantes para establecer una capacidad de procesamiento realista:

Estimación sobre la cantidad y los tipos de usuarios que utilizarán la aplicación o página web.
El comportamiento de los usuarios; es decir, qué acciones llevarán a cabo cuando utilicen la aplicación.
Los tipos de conexiones que afectarán la respuesta del sistema y, en última instancia, también afectarán la experiencia del usuario.
Los efectos de las pausas y las demoras en el sistema.

La capacidad de procesamiento en un escenario de la vida real

Aquí les explicaremos el concepto de la capacidad de procesamiento con un ejemplo de la vida real.

Imaginemos que hay un puesto de comida rápida llamado “Hamburguesas Sabrosas”. Les sirven hamburguesas y papas a sus clientes.

Supongamos que “Hamburguesas Sabrosas” tiene tres empleados en el puesto, y a cada empleado le lleva 5 minutos servirle la comida al cliente. Por lo tanto, si tienen tres clientes en la fila que serán atendidos por tres trabajadores, significa que “Hamburguesas Sabrosas” puede servirles la comida a tres clientes en 5 minutos.

Por ende, si tenemos que escribir un reporte sobre el rendimiento de “Hamburguesas Sabrosas”, mostraría que su capacidad de procesamiento es de tres clientes cada 5 minutos.

El dilema de “Hamburguesas Sabrosas” es que no importa cuántos clientes tengan esperando su comida, la mayor cantidad que podrán manejar en un intervalo de tiempo específico será siempre la misma (es decir, tres). Esta sería su máxima capacidad de procesamiento.

Si llegan más clientes y comienzan a ponerse en fila para la comida, deberán esperar su turno, por lo que la fila irá alargándose.

El mismo concepto aplica para las pruebas sobre aplicaciones web. Si una aplicación web recibe 100 solicitudes por segundo, pero tan sólo puede manejar 70 solicitudes por segundo, las 30 solicitudes restantes deberán esperar en una cola.

En las pruebas de rendimiento, nos referimos a la capacidad de procesamiento como “Transacciones por segundo” o TPS.

Capacidad de Procesamiento en Pruebas de Performance JMeter:

Es bastante popular utilizar Apache JMeter para realizar Pruebas de Performance de una aplicación de software. JMeter es muy útil para determinar la mayor cantidad de usuarios concurrentes que puede manejar una aplicación, y también proporciona un análisis gráfico para Pruebas de Performance.

JMeter nos proporciona varias formas de registrar el valor de la capacidad de procesamiento. Debajo listaremos algunos de los receptores de JMeter que puedes utilizar para ello:

Reporte Resumen
Reporte Agregado
Gráfica Agregada
Resultados Gráficos

JMeter también proporciona un componente de tiempos de espera, “Constant Throughput Timer” (Tiempo de Espera Constante para Capacidad de Procesamiento), que se puede utilizar para establecer el valor de las Transacciones por Segundo (TPS) para probar la carga de la aplicación.

Ahora les mostraremos el uso de la capacidad de procesamiento en Pruebas de Performance utilizando JMeter.

Supongamos que vamos a llevar a cabo una prueba de ejemplo con 100 hilos concurrentes y vamos a monitorear el valor de la capacidad de procesamiento.

Supongamos que tenemos la última versión de JMeter instalada en nuestro sistema y que ya hemos realizado todas las otras configuraciones. Ahora crearemos un plan de pruebas.

1-   Configuración de la prueba:
Para esta prueba, definiremos cinco elementos “ThreadGroup” (grupo de hilos). Cada uno de estos elementos tendrá un un tiempo de ramp-up distinto (es decir, 0, 15, 25, 35 y 45). El tiempo de ramp-up es la duración para comenzar con cada hilo. Configuraremos 100 usuarios en ese elemento de ThreadGroup. Si queremos configurar una mayor cantidad de usuarios, entonces el tiempo de ramp-up deberá ser mayor.

Estos grupos de hilos tendrá una Petición (“Sampler”) HTTP que generará solicitudes para la página principal de una página web cualquiera (supóngase www.sitioejemplo.com). 

Para el Cao de Uso 1, tendremos un elemento ThreadGroup configurado con 100 hilos, y el tiempo de ramp-up es 0.

El campo “Number of Threads” (número de hilos) será de 100. Esto significa que 100 usuarios enviarán solicitudes a la misma vez. De forma similar, podemos configurar los 4 hilos restantes y establecer su tiempo de ramp-up como 15, 25, 35 y 45. También asignaremos un nombre para las peticiones de cada grupo de hilos. Como mencionamos antes, estas peticiones HTTP apuntarán a la página principal de una página web cualquiera.

Es necesario ejecutar este grupo de hilos en una secuencia apropiada. Para lograr esto, selecciona “Test Plan” (Plan de Pruebas) en el panel de control y marca “Run Thread Groups consecutively” (Ejecutar Grupo de Hilos de forma consecutiva).

2-   Análisis de los resultados de la prueba:
El “Reporte Agregado” es un receptor que se utiliza para analizar y observar los resultados de las pruebas. Para utilizar este receptor, haz clic derecho en “Test Plan” y selecciona:

Add  Listener  Aggregate Report
(Agregar Receptor Reporte Agregado)

Luego, haz clic en el ícono de inicio para ejecutar la prueba.

Ahora, veamos cómo comprender los resultados de la capacidad de procesamiento utilizando el Reporte Agregado.

El primer grupo de hilos con tiempo de ramp-up 0 muestra que todos los hilos colocaron una carga instantánea sobre el servidor ya que comenzaron todos al mismo tiempo. Este escenario tiene una capacidad de procesamiento bastante alta, pero no es práctica. Por ende, esto no tendrá un resultado realista.

El segundo y tercer grupo de hilos tienen un tiempo de ramp-up en un rango más realista, por lo que será más probable que tengan un rendimiento de capacidad de procesamiento y unos tiempos de carga más apropiados.

Los grupos de hilos número cuatro y cinco tienen un tiempo de ramp-up mayor, por lo que la capacidad de procesamiento disminuirá.

Por lo tanto, el segundo y tercer grupo de hilos tendrán resultados más confiables.

Aspectos importantes para recordar cuando probamos la Capacidad de Procesamiento:

La decisión de implementar un nuevo lanzamiento o cambio depende de la capacidad de la aplicación de manejar un TPS específico. Por ende, un plan de Pruebas de Performance debe tener objetivos de capacidad de procesamiento bien definidos. Sin embargo, tendremos que asegurarnos de que estos objetivos sean realistas y representen las verdaderas características del ambiente de producción.

El plan de pruebas es en vano si lo aprobamos con condiciones poco realistas. Por ejemplo, el plan de pruebas que habíamos descrito en la sección anterior tenía un mayor valor de capacidad de procesamiento para el primer grupo de hilos, pero no representaba el verdadero escenario del ambiente en producción. Es por ello que, si utilizamos esos métodos, no podremos realmente hacernos una idea de si nuestra aplicación podrá manejar la carga actual o no. Por ende, es de vital importancia configurar pruebas apropiadas.

Ahora hablaremos sobre algunos aspectos importantes que debemos considerar para probar el rendimiento de la capacidad de procesamiento.

Diseño de Pruebas Apropiado:
El diseño de las pruebas evalúa si la capacidad de procesamiento generada es realista o no. En el escenario de la vida real, cada solicitud puede ser diferente y puede desencadenar procesos complicados para los resultados que se requieren. Por ende, necesitaremos manipular las pruebas de acuerdo con el ambiente en producción que se espera.

Representación de Usuarios Reales:
Cada usuario de la aplicación puede tener solicitudes que afecten los recursos del Sistema. Por ende, si no se representan usuarios reales en el escenario de prueba, los resultados pueden indicar un uso inexacto de recursos en el back-end y, por lo tanto, la prueba no está emulando las condiciones apropiadas.

Considerar Pausas y Demoras:
En un ambiente en producción, los usuarios necesitan tiempo para pensar, entender y procesar información, ingresar información en los distintos campos, etc. Sin embargo, los servidores siguen utilizando recursos durante esas pausas. Por ende, intenta incorporar estos comportamientos de los usuarios en tus scripts.

Velocidad de la Conexión:
Los usuarios de la aplicación se conectan a ella utilizando distintas velocidades de red, regiones, o a través de redes móviles. Por lo tanto, también es necesario elegir una velocidad que represente el tipo de conexiones de los usuarios.

Conclusión:

En resumen, la capacidad de performance es un indicador de rendimiento vital para las aplicaciones web. Sin embargo, depender de las métricas relacionadas con la capacidad de procesamiento no es suficiente. Por consiguiente, se debe también evaluar la latencia y los tiempos de respuesta. También es realmente importante definir una capacidad de procesamiento realista para cumplir con los objetivos establecidos para las Pruebas de Performance.