Pruebas de estrés

La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la versión revisada el 3 de diciembre de 2021; las comprobaciones requieren 2 ediciones .

La prueba de carga es un subtipo  de prueba de rendimiento, que recopila indicadores y determina el rendimiento y el tiempo de respuesta de un sistema o dispositivo de software y hardware en respuesta a una solicitud externa para establecer el cumplimiento de los requisitos para este sistema (dispositivo).

Para estudiar el tiempo de respuesta del sistema ante cargas altas o pico, se realizan pruebas de estrés , en las que la carga creada sobre el sistema supera los escenarios normales para su uso. No existe una línea clara entre las pruebas de carga y las pruebas de estrés, pero no deben confundirse, ya que estos tipos de pruebas responden a diferentes preguntas comerciales y utilizan una metodología diferente.

En general, las pruebas de carga se refieren a la práctica de modelar el uso esperado de una aplicación emulando el trabajo de varios usuarios al mismo tiempo. Por lo tanto, dichas pruebas son más adecuadas para sistemas multiusuario, y la mayoría de las veces utilizan una arquitectura cliente-servidor (por ejemplo, servidores web). Sin embargo, otros tipos de sistemas de software se pueden probar de manera similar. Por ejemplo, se puede hacer que un editor de texto o gráficos lea un documento muy grande; y el paquete financiero es generar un informe basado en datos de varios años. La prueba de carga diseñada más adecuadamente da resultados más precisos.

En el caso ideal, los criterios para el éxito de las pruebas de carga son los requisitos de rendimiento del sistema, que se formulan y documentan en la etapa de desarrollo de los requisitos funcionales del sistema antes de programar las principales soluciones arquitectónicas. Sin embargo, a menudo sucede que dichos requisitos no se formularon claramente o no se formularon en absoluto. En este caso , la primera prueba de carga será una prueba de carga exploratoria y se basará en suposiciones razonables sobre la carga esperada y el consumo de recursos de hardware . 

Uno de los mejores enfoques para usar pruebas de carga para medir el rendimiento del sistema es realizar pruebas en la etapa inicial de desarrollo. Las pruebas de carga en las primeras etapas de preparación de una solución arquitectónica para determinar su viabilidad se denominan pruebas de "prueba de concepto".

Algunos principios

Unicidad de las solicitudes: incluso habiendo formado un escenario realista para trabajar con el sistema en función de sus estadísticas de uso, debe comprender que siempre habrá excepciones a este escenario.

Tiempo de respuesta del sistema: en general, el tiempo de respuesta del sistema obedece a la función de distribución normal . En particular, esto significa que, teniendo un número suficiente de mediciones, es posible determinar la probabilidad con la que la respuesta del sistema a una solicitud se encontrará dentro de un intervalo de tiempo determinado.

La dependencia del tiempo de respuesta del sistema del grado de distribución de este sistema: la variación de la distribución normal del tiempo de respuesta del sistema a una solicitud es proporcional a la relación entre el número de nodos del sistema que procesan dichas solicitudes en paralelo y el número de solicitudes por nodo. Es decir, la dispersión de los valores de tiempo de respuesta del sistema se ve afectada simultáneamente por la cantidad de solicitudes que caen en cada nodo del sistema y la cantidad de nodos en sí, cada uno de los cuales agrega una cantidad aleatoria de demora en el procesamiento de las solicitudes.

Variación en el tiempo de respuesta del sistema: con un número suficientemente grande de mediciones del valor del tiempo de procesamiento de la solicitud en cualquier sistema, siempre habrá solicitudes cuyo tiempo de procesamiento exceda los máximos definidos en los requisitos; además, cuanto mayor sea el tiempo total del experimento, mayores serán los nuevos máximos. Este hecho se tiene en cuenta al formar los requisitos para el rendimiento del sistema, así como durante las pruebas de carga periódicas.

Fidelidad del perfil de carga: la fidelidad del perfil de carga requerida es más costosa cuantos más componentes contiene el sistema. A menudo no es posible tener en cuenta todos los aspectos del perfil de carga para sistemas complejos, ya que cuanto más complejo sea el sistema, más tiempo se dedicará a diseñar, programar y mantener un perfil de carga adecuado para él, lo que no siempre es necesario. El enfoque óptimo en este caso es equilibrar el costo de desarrollar una prueba y la cobertura de la funcionalidad del sistema, como resultado de lo cual existen supuestos sobre el impacto en el rendimiento general de una u otra parte del sistema bajo prueba.

Caja de herramientas

Algunas herramientas de prueba de carga [1] [2] :

EN Nombre del fabricante Comentarios
OpenSTA 'Arquitectura de prueba de sistema abierto' Software gratuito para pruebas de carga/estrés, con licencia GNU GPL. Utiliza una arquitectura de aplicaciones distribuidas basada en CORBA . Hay disponible una versión de Windows, aunque existen problemas de compatibilidad con Windows Vista. El soporte finalizó en 2007.
Probador de rendimiento racional de IBM IBM Basado en el entorno de desarrollo Eclipse , software que permite crear una gran carga y medir el tiempo de respuesta para aplicaciones con arquitectura cliente-servidor. Requiere licencia.
jmetro Abra el proyecto Apache Jakarta Kit de herramientas multiplataforma basado en Java que le permite realizar pruebas de carga utilizando conexiones JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP. Te permite crear una gran cantidad de solicitudes desde diferentes computadoras y controlar el proceso desde una de ellas.
HP LoadRunner HP Una herramienta de prueba de carga desarrollada originalmente para emular el trabajo de una gran cantidad de usuarios simultáneos. También se puede utilizar para pruebas unitarias o de integración .
Carga completa Oso inteligente Producto propietario que permite cargar aplicaciones web de prueba
SilkPerformer Microenfoque (Borland)
Cerco Software para perros Joe Siege es una herramienta de prueba de carga del servidor web. [3]
Sistema de equipo de Visual Studio microsoft Visual Studio proporciona una herramienta de prueba de rendimiento que incluye pruebas de carga/unidad
QPrueba cuota
httperf
QALoad compuware ltd.
(El) molinillo
WebCARGAR Software RadView Herramienta de pruebas de carga para aplicaciones web y móviles, incluidos paneles web para análisis de pruebas de rendimiento. Se utiliza para cargas de trabajo a gran escala que también se pueden generar desde la nube. con licencia. [cuatro]

Métricas de rendimiento

Uno de los resultados obtenidos durante las pruebas de carga y utilizado para análisis posteriores son los indicadores de rendimiento de la aplicación.

El consumo de recursos de la CPU es una métrica que muestra cuánto tiempo fuera de un intervalo específico determinado dedicó el procesador a los cálculos del proceso seleccionado. En los sistemas modernos, un factor importante es la capacidad de un proceso para ejecutarse en varios subprocesos, de modo que el procesador pueda realizar cálculos en paralelo. El análisis del historial de consumo de recursos de la CPU puede explicar el impacto en el rendimiento general del sistema de los flujos de datos procesados, la configuración del sistema operativo y de la aplicación, la computación de subprocesos múltiples y otros factores.

El consumo de RAM es una métrica que muestra la cantidad de memoria utilizada por una aplicación. La memoria usada se divide en varias categorías:

Cuando se ejecuta una aplicación, la memoria se llena con referencias a objetos que, si no se usan, pueden limpiarse mediante un proceso automático especial llamado recolector de elementos no utilizados . El tiempo que tarda el procesador en limpiar la memoria de esta manera puede ser significativo cuando el proceso ha consumido toda la memoria disponible (en Java, el llamado "GC completo persistente") o cuando al proceso se le han asignado grandes cantidades de memoria que necesita ser limpiado. Durante el tiempo que se tarda en limpiar la memoria, se puede bloquear el acceso de un proceso a las páginas de la memoria asignada, lo que puede afectar el tiempo de procesamiento final de ese proceso.

El consumo de recursos de red es una métrica que no está directamente relacionada con el rendimiento de la aplicación, pero sus indicadores pueden indicar los límites de rendimiento del sistema en su conjunto.

El rendimiento del subsistema de E/S puede afectar significativamente el rendimiento del sistema, por lo que recopilar estadísticas sobre el trabajo con unidades puede ayudar a identificar cuellos de botella en esta área. Una gran cantidad de lecturas o escrituras puede hacer que el procesador quede inactivo mientras espera que los datos se procesen desde el disco y, como resultado, aumente el consumo de recursos del procesador y aumente el tiempo de respuesta.

El tiempo de ejecución de una solicitud por parte de una aplicación sigue siendo uno de los indicadores más importantes del rendimiento de un sistema o aplicación. Este tiempo se puede medir en el lado del servidor como una medida del tiempo que tarda el lado del servidor en procesar una solicitud; y en el cliente, como indicador del tiempo total requerido para la serialización y deserialización , reenvío y procesamiento de la solicitud. Sin embargo, no todas las aplicaciones de pruebas de rendimiento pueden medir ambos tiempos.

Notas

  1. Molyneaux, I. El arte de las pruebas de rendimiento de aplicaciones: ayuda para programadores y control de calidad. - O'Reilly Media, 2009. - P. 130. - 158 p. — ISBN 9780596555436 .
  2. Sosinsky, B. Biblia de computación en la nube. - Wiley, 2010. - Pág. 121. - ISBN 9781118023990 .
  3. Página de inicio de asedio . Consultado el 16 de noviembre de 2013. Archivado desde el original el 20 de noviembre de 2013.
  4. ^ "Revisión de WebLOAD: Introducción a la herramienta de prueba de carga de WebLOAD" . Consultado el 12 de septiembre de 2015. Archivado desde el original el 13 de octubre de 2015.

Literatura