Contactos

Cómo probar informes para la carga. Cargar el servicio de prueba de MeadMe. Cómo determinar una tasa de demora razonable

Pruebas de estrés

Pruebas de estrés (Esp. Prueba de carga.) - Definición o recopilación de indicadores de rendimiento y tiempo de respuesta de un software y un sistema técnico o dispositivo 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 en cargas altas o picos, se realiza las pruebas de estrés, en las que la carga generada por el sistema excede los escenarios normales de su uso. No hay límite claro entre las pruebas de carga y estrés, pero estos conceptos no valen la pena de mezclar, ya que estos tipos de pruebas responden a diferentes problemas comerciales y utilizan una metodología diferente.

Cargar pruebas de software

Término pruebas de estrés Se puede utilizar en varios valores en un entorno de prueba de software profesional. En general, significa la práctica de modelar el uso esperado de la aplicación utilizando la emulación de varios usuarios al mismo tiempo. Por lo tanto, dichas pruebas son más adecuadas para sistemas de múltiples usuarios, más a menudo, utilizando la arquitectura del servidor cliente (por ejemplo, servidores web). Sin embargo, otros tipos de sistemas de software se pueden probar de una manera similar. Por ejemplo, se puede hacer un editor de texto o gráfico para leer un documento muy grande; Y el paquete financiero es generar un informe basado en datos durante varios años. La prueba de carga más diseñada proporciona resultados más precisos.

El objetivo principal de las pruebas de carga es, creando una carga definida por la carga (por ejemplo, a través de usuarios virtuales) y, por lo general, utilizando software y hardware idénticos, monitoree el rendimiento del sistema.

Ejemplo 1:

El servicio web con la funcionalidad de la canasta del comprador está diseñada para 100 usuarios de trabajo simultáneamente que siguen un cierto escenario (medidas en las proporciones especificadas):

  • 25 usuarios ve las mercancías y salen del sistema.
  • 25 usuarios agregan productos a la canasta, sacándolo y abandone el sistema.
  • 25 usuarios usan la función de retorno y salga del sistema.
  • 25 usuarios están incluidos en el sistema y no muestran ninguna actividad.

En este caso, las pruebas de carga deben emular el escenario de trabajo típico descrito anteriormente con un servicio web para asegurarse de que el sistema esté listo para la operación. Al mismo tiempo, el rendimiento del rendimiento del sistema en su conjunto o cada nodo del sistema se puede eliminar para su análisis.

En el caso ideal, como criterios para el éxito de las pruebas de carga, los requisitos para el rendimiento del sistema, que se formulan y documentan en la etapa de desarrollo de los requisitos funcionales del sistema antes del inicio de la programación de las principales soluciones arquitectónicas. Sin embargo, a menudo sucede que tales requisitos no estaban claramente formulados o no formulados en absoluto. En este caso, la primera prueba de carga será juicio (pruebas de carga exploratorias) Y se basa en suposiciones razonables sobre la carga esperada y el consumo del hardware de los recursos.

Uno de los enfoques óptimos para usar las pruebas de carga para medir el rendimiento del sistema está probando en la etapa del desarrollo temprano. Las pruebas de carga en las primeras etapas de la preparación de la solución arquitectónica para determinar su longitud de longitud se denomina pruebas de "Prueba de concepto".

Principios básicos de pruebas de carga.

A continuación se muestran algunos hechos experimentales resumidos en los principios utilizados en la prueba de desempeño en su totalidad y aplicable a cualquier tipo de prueba de rendimiento (en particular, para cargar pruebas).

1. singularidad de las solicitudes.

Incluso haber formado un escenario realista con un sistema basado en sus estadísticas de uso, es necesario entender que siempre habrá excepciones a este escenario.

Ilustración de varias dispersiones de distribución para el momento de la ejecución de las solicitudes de X e Y.

Cuándo Ejemplo 1. Puede ser un usuario agregado a diferente de todos los demás. páginas únicas Servicio web.

2. Tiempo de respuesta del sistema

En general, el tiempo de respuesta del sistema está sujeto a la función de distribución normal.

En particular, esto significa que tener un número suficiente de mediciones, se puede determinar la probabilidad con que la respuesta del sistema a la solicitud caerá en uno u otro intervalo de tiempo.

3. La dependencia del tiempo de respuesta del sistema en el grado de distribución de este sistema.

La dispersión de la distribución normal del tiempo de respuesta del sistema a la solicitud es proporcional a la relación con la cantidad del número de nodos del sistema, paralelo para procesar dichas solicitudes y el número de solicitudes por nodo.

Es decir, el número de solicitudes de cada número de sistema y el número de nodos, cada uno de los cuales agrega algunos de los cuales agrega un valor de retardo aleatorio a la dispersión del tiempo de respuesta del sistema.

4. Disparador de tiempo de respuesta del sistema

Desde las declaraciones 1, 2 y 3, también se puede concluir que con un número suficientemente grande de mediciones del tiempo de procesamiento de consulta en cualquier sistema, siempre habrá solicitudes, el tiempo de procesamiento que excede los máximos definidos en los requisitos; Además, cuanto más el tiempo total del experimento, mayor será el nuevo Maxima.

Este hecho debe tenerse en cuenta al formar los requisitos para el rendimiento del sistema, así como durante las pruebas de carga regulares.

5. Precisión de la reproducción de perfiles de carga.

La precisión requerida de los perfiles de carga de la carga es más costosa que el más componente contiene el sistema.

A menudo es imposible tener en cuenta todos los aspectos del perfil de carga para sistemas complejos, ya que más difícil es el sistema, cuanto más tiempo se gasta en el diseño, la programación y el soporte del perfil de carga adecuado, que no siempre es una necesidad. . Enfoque óptimo En este caso, se está equilibrando entre el valor del desarrollo de la prueba y el recubrimiento de la funcionalidad del sistema, como resultado de qué suposiciones sobre el efecto sobre la productividad general de una u otra parte del sistema que se está probando.

Toolkit para pruebas de rendimiento

Cabe señalar que para la mayoría de los tipos de pruebas de rendimiento utiliza el mismo kit de herramientas que puede realizar tareas típicas.

Existe una comprensión errónea común de que las herramientas para el sistema de prueba de carga son las herramientas iguales en el principio de grabación y reproducción como herramientas para la automatización de las pruebas de regresión. Las herramientas de prueba de carga funcionan en el nivel del protocolo, mientras que los instrumentos para la automatización de las pruebas de regresión trabajan a nivel de los objetos de la interfaz gráfica de usuario.

Hay varias herramientas para detectar e investigar problemas en varios nodos del sistema. Todos los nodos del sistema se pueden clasificar de la siguiente manera:

  • Solicitud,
  • Base de datos,
  • Neto,
  • Tratamiento en el lado del cliente,
  • Balanceo de carga.

También se debe tener en cuenta la aparición de aplicaciones de Network Business to-Business (B2B) utilizando el Acuerdo de Nivel de Servicio (o SLA, Acuerdo de Nivel de Servicio). La creciente popularidad de las aplicaciones B2B llevó al hecho de que cada vez más aplicaciones van a una arquitectura orientada al servicio, en cuyo caso el intercambio de información se produce sin la participación de los navegadores web. Un ejemplo de tal interacción puede ser una Oficina de Servicios Turísticos que solicite información sobre un cierre vuelo entre San Petersburgo y Omsk, mientras que la aerolínea está obligada a proporcionar una respuesta dentro de los 5 segundos. A menudo, la violación del tratado de SLA amenaza una multa grande.

Las herramientas más populares para las pruebas de carga se presentan a continuación.

POR Nombre del productor Comentarios
OpenSta. "Arquitectura de prueba de sistema abierto" Software gratuito para pruebas de carga / estrés, GNU con licencia GPL. Utiliza la arquitectura de la aplicación distribuida basada en corba. Versión disponible en Windows, aunque hay problemas de compatibilidad con Windows Vista.. Soporte terminado en 2007.
IBM Rational Performance Tester IBM. Entorno de desarrollo de software basado en Eclipse que le permite crear una carga de grandes volúmenes y medir el tiempo de respuesta para aplicaciones con la arquitectura del cliente-servidor. Requiere licencias.
JMETER. Proyecto abierto Apache Jakarta Project Basado en Java Cross-Platform Toolkit, que permite pruebas de carga utilizando conexiones JDBC / FTP / LDAP / SOAP / JAP / JMS / POP3 / HTTP / TCP. Hace posible crear una gran cantidad de solicitudes de diferentes computadoras y controlar el proceso de uno de ellos.
Hp loadrunner. HP. Herramienta para pruebas de carga, diseñada originalmente para emular una gran cantidad de usuarios paralelos. También se puede utilizar para pruebas de unidad o de integración.
Silkperformer Foco micro
Prueba de carga de estudio visual Microsoft. Visual Studio proporciona una herramienta de prueba de rendimiento que incluye pruebas de carga / unidad
LoadComplete. SmartBear.

Rendimiento principal de indicadores (métricas)

Uno de los resultados obtenidos con pruebas de carga y utilizado en el futuro para el análisis son los indicadores de rendimiento del rendimiento. El principal de ellos está desmontado a continuación.

1. Consumo de los recursos del procesador central (CPU,%).

La métrica, que muestra la cantidad de tiempo del intervalo definido especificado por el procesador al calcular para el proceso seleccionado. EN sistemas modernos Un factor importante es la capacidad del proceso para trabajar en varios hilos, para que el procesador haga cálculos en paralelo. Un análisis del historial de consumo de recursos del procesador puede explicar el impacto en el desempeño general del proceso de transmisiones de datos procesadas, configuraciones de aplicaciones y sistema operativo, multopezas de cálculos y otros factores.

2. Consumo memoria de acceso aleatorio (Uso de la memoria, MB)

Métrico, mostrando la cantidad de memoria utilizada por la aplicación. La memoria utilizada se puede dividir en tres categorías:

  • Virtual: el volumen del espacio de direcciones virtuales que utiliza el procesador. Este volumen no implica necesariamente, use el espacio de disco o la RAM adecuados. El espacio virtual, por supuesto y el proceso, puede limitarse a la capacidad de descargar las bibliotecas necesarias.
  • Privado: el volumen del espacio de direcciones ocupado por el procesador y no se comparte con otros procesos.
  • Conjunto de trabajo: un conjunto de páginas de memoria utilizadas recientemente por el proceso. En el caso, cuando la memoria libre es suficiente, las páginas permanecen en el conjunto, incluso si no se usan. En el caso de que haya poca memoria libre, las páginas utilizadas se eliminan.

Cuando la aplicación se está ejecutando, la memoria se llena con referencias a objetos que, en caso de no uso, se pueden limpiar mediante un proceso automático especial llamado "colector de basura" (inglés. Recolector de basura). El tiempo dedicado a un procesador de limpieza de memoria de tal manera puede ser significativo, en el caso de que el proceso tomó toda la memoria disponible (en Java, el llamado "GC completo permanente") o cuando el proceso se resalte grandes volúmenes de memoria que Necesito limpieza. Durante un tiempo requerido para limpiar la memoria, el acceso de proceso a las páginas de memoria asignadas se puede bloquear, lo que puede afectar el tiempo de procesamiento final por este proceso de datos.

3. Consumo de recursos de red.

Esta métrica no está directamente relacionada con el desempeño de la solicitud, sin embargo, sus indicadores pueden indicar el rendimiento del sistema en su conjunto.

Ejemplo 3:

La aplicación del servidor procesando la solicitud del usuario, le devuelve una transmisión de video con un canal de red de 2 megabit. El requisito indica que el servidor debe manejar 5 solicitudes de usuario al mismo tiempo.

La prueba de carga ha demostrado que el servidor de manera efectiva puede proporcionar datos solo para 4 usuarios simultáneamente, ya que la corriente multimedia tiene una tasa de bits de 500 kilóbitos. Es obvio que la provisión de este hilo 5 usuarios es simultáneamente imposible debido al exceso del ancho de banda del canal de red, lo que significa que el sistema no satisface los requisitos de rendimiento especificados, aunque el consumo de procesadores y recursos de memoria puede ser bajo.

4. Trabajar con el subsistema de disco (I / O, espera)

Trabajar con el subsistema de disco puede influir significativamente en el rendimiento del sistema, por lo tanto, la recopilación de estadísticas de trabajo de disco puede ayudar a identificar cuellos de botella en esta área. Un gran número de lecturas o registros puede llevar a un procesador permanente que espera el procesamiento de datos del disco y, como resultado, un aumento en el consumo de la CPU y aumentando el tiempo de respuesta.

5. Tiempo de ejecución de tiempo de consulta (Solicite tiempo de respuesta, MS)

El tiempo de ejecución de la solicitud de solicitud sigue siendo uno de los indicadores de desempeño más importantes del sistema o aplicación. Esta vez se puede medir en el lado del servidor, como un indicador del tiempo requerido por la pieza del servidor para procesar la solicitud; Y en el cliente, como indicador de todo el tiempo completo, que se requiere para la serialización / deserialización, envío y procesamiento de la solicitud. Cabe señalar que no cada solicitud de pruebas de rendimiento puede medir ambos de estos tiempos.

ver también

Enlaces

  • Parque infantil de servicios para sitios de prueba y software (RUS.)
  • El portal de especialistas en pruebas y software de garantía de calidad (RUS): el proyecto está dedicado a probar y mejorar la calidad del software.
  • Base de conocimiento del probador (RUS) - BACKTRINGERS, pruebas automatizadas, pruebas de carga, pruebas de usabilidad, comunidad, impresión, libros
  • Automatización de pruebas de carga (RUS.)
  • Notas sobre pruebas de carga (RUS.)

Literatura

  • Lisa Crispin, Janet Gregory Pruebas flexibles: Guía práctica para probadores y comandos flexibles \u003d Pruebas ágiles: una guía práctica para probadores y equipos ágiles. - m.: "Williams", 2010. - 464 p. - (Serie de firma Addison-Wesley). - 1000 copias. - ISBN 978-5-8459-1625-9

Fundación Wikimedia. 2010.

Pasando el servidor web en la operación cotidiana, debe asegurarse de que él
Resistirá la carga planificada. Solo creando condiciones aproximadas para combatir,
Es posible evaluar si la potencia del sistema es suficiente correctamente.
Aplicaciones involucradas en la creación de contenido web y otros factores que afectan
Trabajo del servidor web. En esta situación llegará al rescate. herramientas especiales,
Lo que ayudará a dar una evaluación cualitativa y cuantitativa del trabajo.
como
Nodos web en general e componentes individuales.

Todo va según el plan.

Antes de correr a la batalla, al principio debería ser resuelto lo que queremos.
Obtener como resultado de las pruebas. Después de todo, verifique, como cualquier otro trabajo,
exigir pre-entrenamiento. Con tarea formulada incorrectamente
puede resultar en resultados que no reflejarán completamente lo real
estado. Basado en la carga prevista del servidor web, es necesario
Determinar los criterios de prueba. Establecer lo que será considerado como exitoso
Y cuál es el servicio inaceptable del servicio (por ejemplo, un tiempo de respuesta, carga
Servidor). Tres opciones de prueba distinguen:

  • Prueba de carga - Se determina el rendimiento del sistema.
    Con algunos estrictamente dados en carga previa (planificada, trabajando).
  • Sostenibilidad (estrés) - Se utiliza para verificar los parámetros del sistema.
    En las condiciones anormales y extremas, la tarea principal durante esta prueba es
    Intenta romper el trabajo del sistema. Le permite determinar el mínimo
    Valores requeridos de los recursos del sistema para la operación de la aplicación, evalúe
    Las características límite del sistema y los factores que limitan estas oportunidades.
    También se determina la capacidad del sistema para preservar la integridad de los datos.
    La aparición de situaciones de emergencia independientes.
  • Rendimiento Rendimiento) - Comprobación completa, incluyendo
    Las dos pruebas anteriores están diseñadas para evaluar todos los indicadores del sistema.

Resultado de la prueba - Número máximo de usuarios, que puede
Al mismo tiempo, obtener acceso al sitio web, el número de solicitudes procesadas
Apéndice, o tiempo de respuesta del servidor. Basado en el resultado,
Master web y administrador de red (en el trabajo del servidor y otros
Componentes de red, enrutadores, firewall, almacenamiento en caché y proxy, base
Los datos, etc.) podrán identificar cuellos de botella por adelantado derivados de
El trabajo de componentes desequilibrados y corrige la situación antes.
Incluir el sistema en trabajo real.

Durante las pruebas trabajo simultáneo de varios cientos.
o miles de visitantes
. Para una mayor veracidad, cada uno de los virtuales.
Los usuarios pueden "caminar" en el sitio en el escenario individual y tener personal.
parámetros. También en el proceso de prueba puede simular picos a corto plazo.
cargas cuando el número de visitantes está aumentando de aumento, lo cual es muy
Real para sitios con audiencia desigual. Así que para mantener plenamente
Pruebas, necesitas saber:

  • ¿Cuántos visitantes están programados para tomar en promedio, en la carga máxima,
    tiempo de carga máximo;
  • ¿Pueden varios usuarios tener la misma dirección IP y / o
    Contraseña de inicio de sesión;
  • número promedio de páginas vistas por un usuario, está ahí
    Diferencias en el comportamiento entre usuarios registrados y anónimos,
    Relación cuantitativa entre dichos usuarios visitados por páginas y
    el momento de encontrar al usuario en el nodo;
  • la disponibilidad de páginas dinámicas y páginas cambió dentro de un determinado.
    período, y con qué frecuencia sucede;
  • encendido está involucrado correo electrónico, por ejemplo, para confirmar la autoridad.
    usuario;
  • ¿Qué más información adicional se utiliza para verificar el estado?
    Usuario (cookies);
  • si la confirmación de la autoridad del usuario es requerida por una organización de terceros
    o servidor remoto (por ejemplo, número de tarjeta de crédito), y si
    información presentada para la prueba;
  • ancho de banda de canal disponible, su ancho promedio para uno
    usuario;
  • ¿Puede el trabajo de varios usuarios llamar a la colisión?
  • si se utiliza la conexión HTTPS protegida;
  • es applets java, medios de transmisión, complementos especiales que
    Requerido desde el lado del cliente para apoyarlos;
  • si se utiliza el almacenamiento en caché de páginas;
  • eventos técnicos planificados que pueden afectar el trabajo.
    Servidores y tiempo de ellos (sincronización, archivo, etc.).

Cualquiera de estos parámetros puede afectar el resultado final. No es necesario
Todos los cheques incluyen en una prueba, puede romper la primera tarea para las subtareas.
Por ejemplo, cheque sistema base (Servidores: web, aplicaciones, bases de datos) y
Compruebe los módulos individuales (servlets, scripts, etc., por ejemplo, cheque
Autenticación con una gran cantidad de usuarios). Como resultado,
Las pruebas se emiten gráficos de tres tipos: lineal, no lineal y saturación. EN
Primer caso con un aumento en el tiempo de respuesta de carga (es decir, el procesamiento) permanece
constante. Con un aumento adicional en la carga, el tiempo de respuesta también aumenta.
(casi lineal), y finalmente hay una situación como un ataque de DOS cuando el tiempo
La respuesta está infinitamente aumentando. Ahora que el plan de acción está listo, ve a
Breve descripción de las utilidades que ayudarán a implementarla. Vamos a empezar gratis.

Arquitectura de prueba de sistemas abiertos

OpenSta. (www.opensta.org)
- Más que una aplicación para pruebas, esta es una arquitectura abierta, diseñada.
Alrededor de los estándares abiertos. El proyecto fue establecido en 2001 por un grupo de empresas. Cyrano.,
que apoyó la versión comercial del producto, pero Cyrano se derrumbó, y ahora
OpenSta. se aplica como una solicitud con fuente abierta Sin licencia
GNU GPL trabaja en Windows NT 4.0SP5 / 2000 / XP. Para trabajar requiere datos de Microsoft
Componentes de acceso (MDAC), que se pueden descargar al sitio de la Corporación.

El kit de herramientas actual le permite realizar la prueba de carga HTTP / HTTPS
Servicios, aunque su arquitectura es capaz de mayor. OpenSta. Permite
Cree scripts de prueba en el idioma especializado SCL (Control de script
Idioma). Para simplificar la creación y edición de escenarios utilizados.
Herramienta de script especial. Elija Herramientas - URL canónico,
Se inicia el navegador web. Solo camina en el sitio, recogiendo enlaces que
Guardado en el guión. Todos los parámetros de solicitud pueden ser editados, posible
Sustitución variable. La estructura de la prueba y los titulares se mostrará en pestañas.
En el panel de la izquierda. Las pruebas se combinan convenientemente en conjuntos. Las configuraciones de proxy se establecen en
El script en sí, por lo que puede especificar múltiples servidores. Oportunidad implementada
Organización de pruebas distribuidas, que aumenta realistas, o cuando
Desde una computadora, no puede cargar un servidor poderoso. Cada uno de los coches tales
Los sistemas pueden realizar su grupo de tareas, y el host del repositorio recolecta
y almacenando resultados. Después de la instalación en cada sistema de prueba
Se inicia el servidor de nombres, cuyo trabajo es obligatorio. Soportado
Autenticación del usuario en el recurso web y estableciendo conexiones para
Protocolo SSL. Los parámetros operativos del sistema cargado se pueden monitorear con
Usando SNMP I. ventanas NUEVO TESTAMENTO. Resultados de la prueba incluyendo el tiempo
Respuestas, número de bytes aprobados por segundo, códigos de respuesta para cada solicitud
Y el número de errores se muestran en forma de tablas y gráficos. Usando grandes
Los números de filtro le permiten seleccionar los resultados necesarios. El resultado es posible.
Exportar al archivo CSV. La conclusión de los informes es algo limitada,
Pero en los enlaces del sitio puede encontrar scripts y complementos que se simplifiquen, incluyendo
Análisis de la información recibida.

Apache Jmeter.

Apache Jmeter. (jakarta.apache.org/jmeter)
es una aplicación de código abierto de Java, diseñado para cargar
Pruebas no solo aplicaciones web y su componentes separados (guiones,
Servlets, objetos Java, etc.), pero también servidores FTP, bases de datos (con
utilizando JDBC) y red. La funcionalidad se está expandiendo con los complementos.
SSL se admite (a través de la extensión Secure Sockets de Java). Tal vez sosteniendo
pruebas tanto utilizando la interfaz gráfica como desde línea de comando.
El uso de Java implica la multiplataforma, por lo que JMETER.
Funciona con confianza en varios * Nix-Systems, en Windows de 98 y algunos otros
OS. Aplicar bajo la licencia de Apache.

EN JMETER. Proporciona mecanismos de autorización virtual.
Usuarios, sesiones personalizadas, plantillas, almacenamiento en caché y
El posterior análisis fuera de línea de los resultados de las pruebas, las funciones le permiten formar
La siguiente solicitud, basada en la respuesta del servidor a la anterior. Tengo una oportunidad
Llevar a cabo pruebas distribuidas. En este caso, una de las computadoras es
servidor (bin / jmeter-server.bat) que maneja a los clientes y recoge
Información final.

Es suficiente para ejecutar apachejmeter.jar o en la consola jmither.bat
(Windows) o JMeter.SH (* NIX).

JMETER. tiene un servidor proxy incorporado que está diseñado para grabar
Sesiones, pero puedes usar externas. Antes de probar que necesitas
Cree un plan de prueba que describa una serie de tareas que desea realizar
JMETER.. Debe contener uno o más grupos de flujo (hilo
Grupos) y otros elementos:

  • Controladores lógicos (controladores lógicos);
  • Controladores de muestra (controladores de generación de muestra);
  • Oyentes;
  • Temporizadores (temporizadores);
  • Cumplimiento (afirmaciones);
  • Elementos de configuración (elementos de configuración).

En primer lugar, agregue un grupo de transmisión (Editar - Agregar grupo de hilo). En su
Los ajustes indican el nombre, el número de disparadores, que es
Usuarios virtuales (número de hilos), tiempo de retardo entre lanzamiento
Corrientes (período de rampa), el número de ciclos de ejecución de tareas (recuento de bucle)
Aquí puede determinar la ejecución de una tarea de horario (Sheduler). Más,
Cortado al grupo creado, debe agregar una muestra de la consulta (muestreador) seleccionando
Es de la lista. Para pruebas de carga o pruebas de rendimiento.
Los servidores simplemente seleccione Solicitud HTTP (AGREGAR -SAMPLER - Solicitud HTTP). Aquí
Especifique el nombre, la dirección IP y el puerto del servidor web, el protocolo, el método de transferencia de datos
(Obtenga, publique), redirige parámetros, transferencia de archivos al servidor. Personalizar I.
Haga clic en Ejecutar. La salida de resultado se lleva a cabo utilizando oyentes, cada uno
A su manera, muestra el resultado. Por ejemplo, el gráfico agregado muestra total
Los resultados de la prueba en forma de una tabla y gráficos.

Productos gratuitos, Aloy, terminó, ahora un par de soluciones comerciales.

WATT - Pruebas de aplicación web

Wapt (www.loadtestingtool.com)
Le permite experimentar la estabilidad del sitio web y otras aplicaciones utilizando
Interfaz web, a cargas reales. Desarrollado por la empresa Novosibirsk
SoftLogica LLC. Este es uno de los programas de revisión más fácil de usar. Para
La prueba simple ni siquiera necesita mirar la documentación, la interfaz
Simple, pero no localizado. Trabaja bajo Windows de 98, compatible
y Vista. Para cheque Wapt puede crear muchos virtuales
Usuarios, cada uno con parámetros individuales. Múltiple soportado
Tipos de autenticación y cookies. El guión le permite cambiar los retrasos entre
Solicitudes y generar dinámicamente algunos parámetros de prueba,
Pierde el comportamiento de los usuarios reales tanto como sea posible. En demanda
Varias opciones para el encabezado HTTP pueden ser sustituidas, en la configuración que puede
Especifique la codificación de la página. Agente de usuario, reenvío X para, se indican parámetros IP.
En la configuración del script. Los valores de los parámetros de la consulta se pueden calcular
de varias maneras, incluidas las definidas por la respuesta del servidor a la anterior
Solicitud utilizando variables y funciones. Trabajo apoyado en protegido
Protocolo HTTPS (y todos los tipos de servidores proxy). Escenarios creados almacenados en
El archivo de formato XML se puede reutilizar. Además del rendimiento estándar y
Estrés, hay varias otras pruebas que le permiten determinar
Número máximo de usuarios y prueba el servidor bajo carga en
Por un largo período.

Para las pruebas, debe seleccionar nuevo - escenario, como resultado
El asistente de prueba comenzará. En el primer paso, se indica el tipo de prueba y luego en
Cada ventana está llena por los parámetros de la prueba futura. Aquí puedes especificar
Número fijo de usuarios virtuales, o aumento gradual
indicando el número mínimo y máximo y el intervalo de tiempo, se establece
Pruebas de temporizador. El siguiente paso establece la hora entre clics (Piense
Tiempo), la velocidad de conexión, indica el rango de direcciones IP que serán
Utilizado por los usuarios virtuales. Al presionar la lista de direccion de IP permitirá
Haz una lista de tales direcciones. El Agente de usuario del parámetro HTTP también está configurado.
Se incluye la emulación de proxy. Si es necesario tener usuarios virtuales.
configuraciones individuales, en el siguiente paso del asistente para cada uno de ellos.
Debe crear su perfil haciendo clic en Nuevo o Guardado descargable. En el siguiente
La ventana del programa debe configurar los parámetros del perfil.

Después de presionar el botón está listo, se guarda el script. Ahora para apuntar a
Objeto de prueba, cree un nuevo perfil - Perfil y llena todos los parámetros en
pestañas. Aquí también están disponibles para editar algunos parámetros especificados.
Temprano con el maestro. Indique también la carga de dibujos por virtual.
El usuario, los parámetros de autenticación, usan cookies y otros.
En la pestaña Grabadora, especifique la dirección del sitio, cuya disponibilidad puede ser inmediatamente
Compruebe haciendo clic en Ir. Al mismo tiempo será una solicitud de lanzamiento de la grabadora, que
rastreará las páginas visitadas y escribirá el URI (se mostrarán en
Panel a la izquierda). Cuando se recopila toda la información, haga clic en Ejecutar la prueba. Informes detallados
En forma de gráficos se muestran en el curso de la prueba, al final será
Formado html formado. Como resultado, puede obtener información sobre el tiempo.
Respuesta del servidor con carga creciente, por el número de errores transmitidos y
Byte aceptado, etc.

Neoload.

Neoload. (www.neotys.com)
- otro sistema que le permite realizar pruebas de carga
Aplicaciones web. Escrito en Java, trabaja en computadoras trabajando bajo
Administre Windows NT / 2000 / XP, Linux y Solaris. En el informe puedes obtener
Información detallada sobre cada archivo descargado. Neoload es muy conveniente para
Estimaciones del trabajo de los componentes individuales (AJAX, PHP, ASP, CGI, Flash, Applets y
etc.). Es posible establecer el tiempo de retardo entre las solicitudes (ThinkTime) globalmente
E individualmente para cada página. Las pruebas se realizan como con
Usando una concha gráfica muy conveniente y usando el comando
Filas (utilizando un archivo XML preempleado). Apoya el trabajo S.
Protocolo HTTPS, con proxy HTTP y HTTPS, autenticación básica web y cookies,
Definiendo automáticamente los datos durante la grabación del script, y luego pierde en
Tiempo de prueba. Trabajar con varios perfiles para registrar usuarios.
Se pueden utilizar variables. Al realizar la prueba que puedes usar.
Monitores adicionales (SNMP, Weblogic, WebSphere, Rstat y Windows, Linux,
Solaris) para monitorear y parámetros del sistema en los que funciona.
Servidor web.

Con ayuda Neoload. Se pueden realizar pruebas distribuidas. Uno de
Las computadoras son un controlador, se instalan generadores en el resto.
Cargas (LoadGenerator). El controlador distribuye la carga entre el almacenamiento de carga y
Recoge estadísticas.

El trabajo con los usuarios virtuales es muy conveniente. Usuarios
tienen configuraciones personalizadas, luego se combinan en poblaciones (debería
para ser creado al menos una población), en poblaciones puede establecer un común
Comportamiento (por ejemplo, el 40% de los usuarios de la población son visitados por recursos dinámicos,
20% Leer noticias). Los usuarios virtuales pueden tener un individuo.
Dirección IP, ancho de banda y su script de prueba.

El guión de la prueba futura es muy simple. Ejecutar la solicitud (cuando
El primer lanzamiento deberá ingresar la clave de registro, la versión de 30 días después de
El registro será enviado por correo), seleccione Nuevo proyecto, ingrese el nombre
Proyecto. Después de eso, se mostrará una pequeña punta de además.
Las acciones, al presionar la grabación de inicio iniciarán un navegador web, todos los movimientos serán
grabado. Después de terminar, presione Detener la grabación o cerrar el navegador.
Se lanzará un asistente que ayudará a crear usuarios virtuales y
Produce búsqueda automática Parámetros dinámicos en páginas grabadas,
Exhibe el valor promedio de THINKIET. Componentes de la página (HTML, imágenes, CSS)
Guardar por separado. Para obtener el resultado, debe pasar por tres pasos:

  • Diseño: configurando el proyecto, aquí hay tres pestañas. Se especifica el repositorio.
    Páginas web y configuración de consulta, el usuario virtual se crea en el usuario virtual
    Los usuarios especifican la URL que deben "visitar" y adicionales
    Condiciones desde la pestaña de la izquierda de los campos de acciones. En las poblaciones - Tareas cada uno de los grupos.
    usuarios. Los siguientes pasos pueden seleccionarse en acciones: retraso
    (Configuración del retraso), bucle (repetir), mientras (ciclo), si ... entonces ...
    (Condición), contenedor y contenedor aleatorio (Acciones de grupo), intente ... Captura
    (manejo de errores), detenga el usuario virtual (virtual
    usuario).
  • Tiempo de ejecución: se indican los parámetros de prueba, se realiza la prueba. Aquí B.
    Se muestran pestañas separadas en el curso de las estadísticas de prueba.
  • Resultados: responsable de la retirada de varias estadísticas en forma de tablas y gráficos.

Y además de los valores comunes, se puede seleccionar el uso del sistema de filtro
Información para cualquier parámetro. Si lo desea, el proyecto se conserva para repetido.
usar. Entre los productos presentados la capacidad de comparar los resultados.
La prueba es sólo Neoload..

Usando las utilidades de prueba de carga, puede obtener información sobre
El trabajo de servicio web, toma las medidas necesarias para eliminar identificadas.
Desventajas y garantizan el desempeño requerido.

Productos de Microsoft.

Microsoft ofrece tantos productos que permiten
Pruebe el servidor web bajo carga. eso Microsoft Application STORS
Herramienta.
y Herramienta de análisis de capacidad web. El primero se distribuye como
producto separado y tiene interfaz gráfica. El segundo es parte de
Conjunto de herramientas Servicios de información de Internet 6.0 Herramientas de kit de recursos,
Funciona desde la línea de comandos. Mástil. Más visual, en la creación de la prueba.
Un asistente de prueba simple ayudará, trabajará con cookies, ajuste
Cargas en diferentes URL. El script de prueba se puede crear manualmente o
Grabado utilizando un navegador web y, si es necesario, editado. EN Mosteo.
El nivel de carga (nivel de estrés) se ajusta configurando la cantidad de hilos,
Solicitudes al servidor, y el número de usuarios virtuales
calculado como un producto del número de hilos en el número de sockets, abre cada uno de
hilos. Al final de la prueba, obtenemos un informe simple en el formulario de texto en el que
La información se da en el número de solicitudes procesadas por unidad de tiempo, promedio
Tiempo de retardo, velocidades de transferencia de datos al servidor y desde el servidor, la cantidad
Errores, etc. El informe se puede exportar al archivo CSV. No hay oportunidades para
El procesamiento estadístico no se proporciona, es decir, solo es posible
Estimar el trabajo bajo ciertas condiciones.

Pruebas de estrés - definición o recopilación de indicadores de rendimiento y tiempo de respuesta de un software y un sistema técnico o dispositivo en respuesta a una solicitud externa para establecer el cumplimiento de los requisitos para este sistema (dispositivo). (Wikipedia)

¿Por qué se realiza pruebas de carga:

  • Comprobación y optimización de la configuración del equipo, máquinas virtuales, software de servidor;
  • Evaluación rendimiento máximoque es capaz de soportar un proyecto con escenarios de carga típicos sobre los recursos disponibles;
  • El impacto de los módulos de proyecto para el rendimiento, los escenarios de procesamiento de carga máxima;
  • Estimación de la estabilidad en las cargas máximas durante las pruebas de 24 horas, teniendo en cuenta los factores externos (importaciones, la copia de seguridad, etc.);
  • Detección de restricciones de configuración, métodos de definición para una mayor escalada y optimización.

En general, existen gran cantidad Herramientas para pruebas de carga, tanto OpenSource como comercial. Demosmosamos en los más utilizados y hablemos de sus principales oportunidades.

Herramienta de evaluación comparativa del servidor HTTP de Apache

Libre

Sitio oficial

Los más utilizados, porque Apache es parte de Apache.

AB: //] nombre de host [: puerto] / ruta

donde las opciones básicas necesarias:

C. concurrencia. - el número de consultas simultáneas al servidor (predeterminado 1);
-NORTE. peticiones. - Consultas totales (predeterminadas 1).

Como resultado, recibimos dicho informe:

Nivel de concurrencia: 10 Tiempo necesario para pruebas: 0.984 segundos Solicitudes completas: 100 Solicitudes fallidas: 0 Errores de escritura: 0 Total transferido: 3725507 Bytes HTML transferidos: 3664100 Bytes Solicitudes por segundo: 101.60 [# / SEC] (MEDIO) Tiempo por solicitud: 98.424 (media) Tiempo por solicitud: 9.842 (media, a través de todas las solicitudes concurrentes) Tasa de transferencia: 3696.43 Tiempos de conexión recibidos (MS) Mínimo [+/- SD] Median Max Connect: 1 2 3.6 1 23 Procesado: 63 94 21.5 90 90 173 Esperando: 57 89 21.6 84 166 TOTAL: 64 96 21.5 92 174

pros:

  • Hay en todas partes donde hay apache;
  • No requiere ninguna configuración adicional;
  • Herramienta muy simple.

Minusales:

  • Herramienta muy simple;
  • Solo las pruebas de rendimiento del servidor web: solo una URL son las encuestas, no admite los escenarios de carga, es imposible simular una carga de usuario y evaluar el rendimiento del proyecto desde todos los lados, tanto desde el punto de vista de la infraestructura como en términos de desarrollo.

Joe Dog Siege

Libre

Sitio oficial .

Un poco mas dificil ab Y las tareas necesarias hacen mucho mejor.

El archivo de escenario está establecido las solicitudes de URL y pruebas. Si el script es grande por volumen, puede realizar todas las solicitudes en un archivo separado y en el comando para especificar este archivo al probar:

# CAT URLS.TXT # URLS Archivo para Siege # - http://www.itrix24.ru/ http://www.bitrix24.ru/support/forum/forum1/topic3469/?pagen_1\u003d2 http: // www. bitrix24.ru / Registre / reg.php Post Dominio \u003d Test & Login \u003d Login http://www.itrix24.ru/search/ Publicar

El comando indica el número de usuarios -s, el número de repeticiones -R y el retraso entre los hits -d.

El resultado se puede mostrar en el archivo de registro o inmediatamente en la consola en tiempo real:

HTTP / 1.1 200 0.44 SEC: 12090 BYTES \u003d\u003d\u003e GET / HTTP / 1.1 200 0.85 SEC: 29316 BYTES \u003d\u003d\u003e Obtenga / Soporte / Foro / FORUM1 / HTTP / 1.1 200 0.85 SEC: 29635 BYTES \u003d\u003d\u003e Obtener / Soporte / Foro / FORUM1 / HTTP / 1.1 200 0.34 SEC: 12087 BYTES \u003d\u003d\u003e Obtenga / [...] HECHO. Transacciones: 100 hits Disponibilidad: 100.00% Tiempo transcurrido: 12.66 segundos Datos transferidos: 1.99 MB Tiempo de respuesta: 0.64 segs Tasa de transacciones: 7.90 Rendimiento de transacción: 0.16 MB / SEC Concurrencia: 5.02 Transacciones exitosas: 100 transacciones fallidas: 0 Transacción fallida: 1.06 Transacción más corta: 0.31

También puede tomar del registro de acceso del servidor web de URL, que fuimos a usuarios reales y emulamos la carga de usuarios reales.

pros:

  • Multi-roscado;
  • Puede especificar tanto el número de solicitudes como la duración (tiempo) de las pruebas, es decir, puede emular la carga de usuario;
  • Apoya los escenarios más simples.

Minusales:

  • Muchos recursos;
  • Pocos datos estadísticos y no emulan tales escenarios personalizados como limitar la velocidad de las solicitudes de usuario;
  • No es adecuado para pruebas graves y a gran escala en cientos y miles de arroyos, porque él en sí mismo es un intensivo de recursos, y en un gran número de solicitudes y flujos mucho cargan el sistema.

Apache Jmeter.

Libre

Sitio oficial

Principales características:

  • Escrito en Java;
  • HTTP, HTTPS, SOAP, Base de datos a través de JDBC, LDAP, SMTP (S), POP3 (S), IMAP (S);
  • Consola y gui;
  • Pruebas distribuidas;
  • Plan de prueba - archivo XML;
  • Puede manejar el registro del servidor web como un plan de prueba;
  • Visualización de los resultados en la GUI.

Los resultados se muestran en forma gráfica:

pros:

  • Multiplataforma, porque escrita en Java;
  • Muy flexible, se utilizan muchos protocolos, no solo un servidor web, sino también la base;
  • Controlado a través de la consola y la interfaz GUI;
  • Utilizando los registros directos de Apache y Nginx Web Server como un script con la capacidad de variar la carga en estos perfiles;
  • Una herramienta bastante conveniente y poderosa.

Minusales:

  • Muchos recursos;
  • En las pruebas largas y pesadas a menudo cae por varias razones;
  • La operación estable depende del medio ambiente y la configuración del servidor.

Tsung

Libre

Sitio oficial

Principales características:

  • Escrito en Erlang;
  • HTTP, WEBDAV, SOAP, POSTGRESQL, MYSQL, LDAP, Jabber / XMPP;
  • Consola (GUI a través del complemento lateral);
  • Pruebas distribuidas (millones de usuarios);
  • Fases de prueba;
  • Plan de prueba - XML;
  • Entrada del plan utilizando la grabadora Tsung;
  • Monitoreo de servidores de prueba (Erlang, Munin, SNMP);
  • Herramientas para generar estadísticas y gráficos de registros de trabajo.

Usando sus propios scripts que manejan los registros de registro, puede retirar varios informes de prueba:


pros:

  • Debido a que está escrito en Erlang, está bien escalado, depende de los recursos asignados;
  • Puede realizar el papel de un sistema distribuido, en un gran número de máquinas;
  • Una gran cantidad de sistema probado no solo es servidores web ni bases de datos, sino que también, por ejemplo, un servidor XMPP: puede enviar mensajes, pruebas con autorización;
  • Controle a través de la consola, pero, gracias al soporte de los complementos, puede controlar y usar un complemento de terceros con la interfaz GUI;
  • La presencia en el kit de herramientas Tsung Recorder es un servidor proxy tipo a través del cual puede caminar en un sitio de prueba y grabar inmediatamente como un perfil de carga;
  • Generación de varios gráficos de prueba usando scripts.

Minusales:

  • No hay interfaz GUI;
  • SOLO * SISTEMA NIX.

Wapt

Pagado

Sitio oficial

Principales características:

  • Ventanas
  • Pagado (hay prueba por 30 días / 20 usuarios virtuales);
  • Pruebas del plan de grabación de los navegadores de escritorio y móviles;
  • Dependencia en los planes de prueba (URL posterior dependiendo de la respuesta del servidor);
  • Imitación de usuarios reales (retrasos entre conexiones, limitando la velocidad de los compuestos).

El informe se puede mostrar tanto la tabla como la programación.

No todos los usuarios modernos sistema informático En el trabajo cotidiano, se enfrenta al concepto de "pruebas de carga". Es principalmente familiar para desarrolladores web y todos aquellos que utilizan programas intensivos en recursos. Sin embargo, a veces el conocimiento en este tema puede ser usuarios útiles y ordinarios. Intentemos averiguar por qué todo esto es necesario.

Carga y metas

En primer lugar, vale la pena distinguir claramente los tipos de tales pruebas. Condicionalmente, se pueden dividir en dos clases: verificar la computadora "hierro" con la carga más alta posible o excesiva en cada componente y (sitios web con elementos de pronóstico, programas separados, etc.).

No hace falta decir que la prueba de los sitios está conectada directamente con la prueba de los servidores, que alberga información, así como con servidores web virtuales, que se crean en el proceso de trabajo con programas especializados como Denwer.

Programas de prueba de carga y sus tareas.

Como puedes ver, la relación es muy fuerte aquí. Y si hablamos del "hardware", el sistema de pruebas de carga utilizando utilidades especiales le permite identificar con precisión potenciales problemas al trabajar, por así decirlo, en lo más fácil. Los juegos de computadora modernos con sus requisitos pueden cargar fácilmente el sistema a un estado así que dejará de funcionar en absoluto. Por lo tanto, antes de instalar dicho software en una computadora, puede realizar una serie de pruebas para determinar si el juego puede "tirar" del juego. Según los resultados, se toma la decisión de instalar el programa. En principio, lo mismo se aplica a las aplicaciones que involucran cálculos matemáticos complejos, y el trabajo de diseño, ya que la carga en el mismo procesador o RAM en comparación con el estado habitual del sistema se puede exceder a veces.

En cuanto a la segunda clase, la prueba del sitio y el servidor puede actuar como un tipo de medio universal para predecir su comportamiento en el funcionamiento real. Por ejemplo, puede ser una emulación de la solicitud simultánea de acceso a una gran cantidad de usuarios. Como saben, por este principio, hay ataques DDOS cuando el servidor o el sitio no tienen tiempo para manejar demasiados apelaciones. La prueba de carga del servidor o el sitio se discutirá con más detalle más adelante. Mientras tanto, lidiaremos con la computadora "Hardware". Esto se aplica no solo a los terminales nacionales o de trabajo, sino también los sistemas de servidores físicos reales.

Procesador de prueba

Empecemos, quizás, desde el corazón de cualquier computadora, el procesador central. No es ningún secreto que son los problemas en su trabajo en la mayoría de los casos conducen a las consecuencias más tristes. Muy a menudo se asocia con el sobrecalentamiento. Las pruebas de carga le permiten crear condiciones extremas. Y luego puedes ver cómo afectará su trabajo.

No hace falta decir que la realización de pruebas de carga de este tipo implica el uso de ciertas utilidades. Hoy puedes contar cientos y miles. Pero, según la mayoría de los expertos, el líder en esta área es la aplicación Prime95, que se puede aplicar a los procesadores y a las tiras de RAM. Pero la dirección principal es la verificación del conjunto de chips del procesador.

Cuando se utiliza la utilidad, se recomienda cerrar todas las aplicaciones activas y deshabilitar automáticamente (dormir) para que la computadora no apague la computadora en el proceso de comprobación. Ahora necesita simular el procesador las estrictas condiciones (y el programa puede hacerlo, como ningún otro, realmente establecer chips en las condiciones más difíciles). La prueba en sí se activa desde el menú de opciones donde se selecciona la sección de prueba de tortura. Habrá tipos especificados de operaciones. Los más interesantes aquí son pruebas de mezcla (carga simultánea y en el procesador, y en la "RAM"), así como FFT pequeñas y FFT grandes (aumentando la carga en el procesador al descargar la RAM).

¿Cómo determinar qué prueba de carga ha pasado con éxito? Opinión unificada No hay, pero se cree que si durante al menos 4 horas de errores o fallas en el trabajo de chip, este componente es suficientemente resistente a las cargas excesivas. Pero también sucede que los fallos pueden parecer mucho más tarde, por lo que si tiene una bonita reserva de tiempo, es mejor aumentar el período de prueba hasta las 24 horas (puede aparecer errores y después de medio día).

Verificación de RAM

No menos importante es la prueba de carga de "RAM", que realiza las funciones del llamado Segundo Violín. Para hacer esto, la aplicación MEMTEST86 + es la más adecuada, que es la mejor hasta la fecha.

Para trabajar correctamente con él, necesitas crear disco de inicio o la unidad flash y descargue un terminal de computadora de dicho portador. Después de activar la prueba, tomará bastante tiempo. Solo puedes dejar la computadora por la noche. Esto debería ser suficiente.

Determinar el comportamiento del adaptador gráfico.

Con gráficos, también vale la pena realizar una prueba, ya que los adaptadores de video para una carga excesiva son a menudo la causa de las fallas de la computadora. La herramienta perfecta aquí será el programa Furmark.

Esta utilidad es capaz de calentar el chip gráfico mucho más fuerte de lo que hará un juego tridimensional con requisitos del sistema por encima de la media. Como muestra la práctica, se crean las condiciones de manera que la tarjeta de video puede comenzar a recopilar ya en un período de 15 a 30 minutos después del inicio de las pruebas.

Además, se pueden utilizar utilidades especiales diseñadas para juegos específicos. Por ejemplo, aplicaciones de prueba como Alien VS Predator, S.T.A.L.K.E.R.R.R.R.R.R. O algo más así. Como regla general, se distribuyen completamente gratis, y con su ayuda puede establecer con precisión cómo se comportará el sistema después de instalar el paquete de juegos original.

Para lo que necesita pruebas de servidores y sitios.

Ahora, algunas palabras sobre cuáles son las pruebas del sitio y un servidor web. Alrededor de un aspecto (los ataques de DDOS) ya se ha dicho. Ahora veamos esta pregunta por otro lado.

Las pruebas de este tipo se pueden atribuir hasta cierto punto a las herramientas de marketing para predecir el comportamiento del usuario. Por ejemplo, puede simular la situación del comportamiento de una cantidad cierta cantidad (máximo / pico) Al ingresar al sitio, averigüe la cantidad de páginas que se puede ver si un correo electrónico estará involucrado, por ejemplo, en el proceso de pedido de bienes , a medida que la información se puede usar para identificar a los visitantes, permitirá proporcionar acceso simultáneo al sitio a los usuarios en un determinado momento, estará en la demanda de confirmación de los poderes de los usuarios (por ejemplo, al ingresar al número tarjeta bancaria) La efectividad será la introducción de applets Java o el uso de la conexión protegida de HTTPS, etc.

Preguntas de prueba de servidor web (software) y recursos de Internet creados

En principio, casi las mismas tareas establecen ambas pruebas de carga del servidor. Sin embargo, aquí el énfasis se hace un aspecto puramente técnico. Las pruebas le permiten identificar si varios usuarios tienen la misma IP, para aclarar el tiempo de respuesta para enviar solicitudes, averiguar cómo se está reaccionando todo el sistema al protegido o conexión desprotegida¿Cuál será la velocidad de acceso mientras envía simultáneamente demasiadas solicitudes y así sucesivamente?

En este caso (tanto para el sitio, como para un servidor web), muchos asesoran utilizan paquete poderoso Bajo el nombre OpenSta (prueba de la arquitectura del sistema), que permite no solo la verificación, sino también las tareas de romper los componentes para cada elemento de estructura individual utilizando la herramienta de modelado de scripts Script Modeler. Cabe destacar que después de crear un modelo de este tipo, incluso puede verificar la conexión a través del protocolo SSL (se debe iniciar el llamado servidor de nombres). Además, los resultados se pueden guardar en la sección Host del repositorio, y las pruebas se combinan en los grupos apropiados.

Cual es el resultado?

En principio, es muy. breve información Para las pruebas de carga, porque las pruebas en sí, así como los programas que les permiten llevar a cabo, puede encontrar mucho. Digamos: aquí se presentan las utilidades más populares y se considera la esencia misma de la pregunta. Creo que, después de leer cualquier usuario, al menos un poco se promoverá en la comprensión de los problemas relacionados con las pruebas de carga.

A medida que crecen y complican los sitios y aplicaciones, el principal problema de los desarrolladores se convierte en un alto rendimiento. Todos los estudios modernos sugieren que el número de visitantes, el crecimiento de las ventas y el aumento de tráfico depende directamente del desempeño del sitio. Por lo tanto, es importante prestar atención a la forma en que los usuarios rápidos pueden acceder al sitio en el navegador.

En los últimos años, se han desarrollado muchos métodos y tecnologías avanzados en el campo de la optimización del desempeño. Muchos de estos métodos están destinados a reducir el tamaño de las páginas web descargables, JavaScript optimiza y limita el número de solicitudes HTTP individuales.

Este artículo contará sobre los conceptos básicos y las herramientas abiertas para optimizar la productividad. Con él, puede averiguar qué tan rápido responde su servidor a las solicitudes de usuario y desarrollar un plan individual.

Conceptos básicos

Primero necesitas familiarizarse con los términos y conceptos básicos.

  • El retraso es un indicador de la rapidez con que el servidor responde a las solicitudes de los clientes. Generalmente medido en milisegundos (MS). El retraso también se denomina tiempo de respuesta. Cuanto menor sea este indicador, más rápido, el servidor procesa la solicitud. El retraso se mide en el lado del cliente desde el momento en que se envía la solicitud antes de que se reciba la respuesta. Este indicador incluye recursos de red.
  • El ancho de banda es el número de solicitudes que el servidor puede procesar durante un cierto período de tiempo. Por lo general, este indicador se mide en consultas por segundo.
  • El percentil es una forma de agrupar el porcentaje de resultados de todo el conjunto de datos.

Conceptos básicos de las pruebas de carga.

La prueba de carga es una tecnología de medición de rendimiento del servidor, que es enviar el tráfico HTTP imitado al servidor. Esto le permite encontrar respuestas a tales preguntas:

  • ¿Hay suficiente servidor de recursos (memoria, CPU, etc.) para manejar el tráfico esperado?
  • ¿Es suficientemente rápidamente reaccionar el servidor para proporcionar una buena experiencia de usuario?
  • ¿La aplicación funciona de manera efectiva?
  • ¿El servidor es una escala vertical u horizontal?
  • ¿Hay páginas particulares de recursos a la publicación o llamadas API?

Las pruebas de carga se realizan ejecutando un software especial en una computadora (o en el clúster de la máquina). Este software genera un gran número de solicitudes y las envía a un servidor web en la segunda computadora (o en otra infraestructura). Hay muchas de estas herramientas, más tarde veremos algunos de ellos. En este momento, nos centraremos en los términos generales que serán relevantes sin importar qué medios para las pruebas de carga, elegirá. El software de prueba de carga normal se utiliza para determinar el número máximo de consultas por segundo, lo que puede procesar el servidor. Para hacer esto, el servidor es enviado como sea posible. gran cantidad peticiones; Luego, debe verificar cuántos de ellos el servidor pudo procesar con éxito.

Esto permite a nivel de base para determinar las características máximas del servidor, pero esto no proporcionará mucha información sobre los retrasos, el rendimiento diario y la experiencia del usuario. El servidor Multipulatorio puede devolver mil respuestas por segundo, pero si el procesamiento de cada respuesta toma diez segundos, los usuarios probablemente no esperen.

La tendencia general es la siguiente: cuanto mayor sea la carga (cuantas más solicitudes por segundo), mayor será el retraso. Para obtener una imagen más real del retardo del servidor en una carga determinada, será necesario probarlo varias veces con diferentes consultas. No todas las aplicaciones para probar la carga son capaces de esto, pero un poco más tarde leeremos el WRK2 (esta es una herramienta de línea de comandos para probar una carga que puede realizar esta función).

¿Cómo determinar una tasa de demora razonable?

Tiempo de descarga del sitio web En el rango de 2 a 5 segundos, lo habitual, pero parte del tiempo asociado con un retardo del servidor web suele ser de aproximadamente 50-200 milisegundos. La tasa de retardo perfecta es individual para cada sitio. Depende de una gran cantidad de factores (audiencias, mercado, objetivos del sitio, disponibilidad de una interfaz de usuario o API, etc.). Tenga en cuenta: la mayoría de los estudios muestran que cada pequeña velocidad de velocidad se tiene en cuenta en el rendimiento, e incluso mejoras completamente imperceptibles conducen a mejores resultados en su conjunto.

Planificación de pruebas de carga

Para comprender cómo funciona el servidor y la aplicación web y cómo reaccionan a la carga, se pueden tomar varias acciones comunes. Primero, durante las pruebas debe seguir correctamente recursos del sistema. Luego, debe determinar el número máximo de solicitudes por segundo, lo que puede procesar este servidor. También determinar rendimientoEn el que el retraso del servidor llevará a un bajo rendimiento y a una experiencia de usuario deficiente.

1: Recursos de monitoreo

El software para las pruebas de carga recopilará y proporcionará información sobre solicitudes y retrasos. Pero hay algunos otros indicadores del sistema que deben ser monitoreados para entender qué recursos no tiene suficiente servidor cuando se trabaja con grandes volúmenes de tráfico.

Esto se relaciona principalmente con la carga del procesador y la memoria libre: el monitoreo de estos datos durante una carga alta lo ayudará a tomar decisiones más informadas sobre cómo escalar la infraestructura y dónde enfocar los esfuerzos al desarrollar una solicitud.

Si ya tiene un sistema de monitoreo de Prometheus, grafito o coleccionista, puede recopilar todos los datos necesarios.

Leer también:

Si no hay tal sistema, conecte al servidor web y use las siguientes herramientas de línea de comandos para el monitoreo en tiempo real.

Para monitorear la memoria disponible, use el comando GRATUITO. En combinación con el comando WATCH, los datos se actualizarán cada 2 segundos.

Bandera -h Muestra números en un formato legible.

tallos totales usados \u200b\u200ben caché en caché
MEM: 489m 261m 228m 352k 7.5m 213m
- / + búferes / caché: 39m 450m
Cambio: 0B 0B 0B

El número dedicado en la salida representa la memoria libre después de restar tampón y caché. Nuevo versión gratuita Muestra otros resultados:

Total utilizado Buff / caché compartido gratuito disponible
MEM: 488m 182m 34m 14m 271m 260m
Cambio: 0B 0B 0B

La nueva columna disponible se calcula de diferentes maneras, pero generalmente representa la misma métrica: la cantidad actual de memoria disponible para aplicaciones.

Para monitorear el uso de la CPU en el símbolo del sistema, hay una utilidad de MPSTAT que muestra el número de recursos gratuitos de CPU. De forma predeterminada, la utilidad MPSTAT no está instalada en Ubuntu. Puede instalarlo usando el siguiente comando:

sudo apt-get install sysstat

Cuando inicia Mpstat, debe configurar el intervalo de actualización de datos en segundos:

Mostrará la cadena de encabezado y luego la cadena de estadísticas y se actualizará cada dos segundos:

Linux 4.4.0-66-genérico (Ejemplo-Server) 21/08/2017 _x86_64_ (4 CPU)
08:06:26 PM CPU% usr% bonito% sys% iowait% irq% suave% robo% invitado% gnice% inactivo
08:06:28 PM Todos los 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
08:06:30 PM Todos los 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

La columna% inactiva muestra qué porcentaje de recursos de CPU no se utiliza. La carga del procesador a menudo se divide en diferentes categorías (CPU de usuario y CPU del sistema).

2: Determinación de la velocidad máxima de respuesta.

Como se mencionó anteriormente, la mayoría de los programas de prueba de carga son particularmente adecuados para encontrar la velocidad máxima de la respuesta del servidor web. Como regla general, es necesario especificar solo la competitividad y la duración de las pruebas.

La competencia es un indicador que muestra la cantidad de conexiones paralelas que el servidor puede procesar. El valor predeterminado de 100 es adecuado en la mayoría de los casos, pero puede elegir un valor individual. Para hacer esto, debe revisar los MaxClients, MaxThreads Server y otros parámetros similares.

También deberá seleccionar la URL para las pruebas. Si su software solo puede procesar una URL a la vez, vale la pena realizar múltiples pruebas para diferentes URL, ya que los requisitos de procesamiento pueden variar mucho dependiendo de la página. Por ejemplo, los requisitos para descargar la página de inicio del sitio y las páginas del producto son diferentes.

Algunos software para pruebas de carga le permite especificar de inmediato varias URL que deben ser verificadas. Esto le permite imitar con mayor precisión tráfico real. Si tiene datos sobre el uso del sitio (de software analítico o registros de servidores), puede aplicar estos datos en las pruebas.

Superando las URL, ejecutar pruebas. Asegúrese de que el software envíe muy rápidamente las solicitudes. Si el software le permite seleccionar una velocidad de consulta, seleccione el valor que seguramente será demasiado alto para su servidor. Si el software le permite establecer un retraso entre las solicitudes, reduzca este valor a cero.

El uso de procesadores y recursos de memoria aumentará. Los recursos de procesador gratuitos pueden alcanzar el 0%, y el cliente puede obtener un error de conexión. Esto es normal porque el servidor funciona en el límite de oportunidades.

Cuando se termina las pruebas, el software mostrará datos estadísticos, incluido el número de consultas por segundo. Preste atención al tiempo de respuesta: es probable que este indicador sea muy malo, ya que el servidor debe estar extremadamente sobrecargado durante la prueba. Por lo tanto, el número de solicitudes por segundo no es un indicador exacto del ancho de banda máximo del servidor, pero este es un buen comienzo para una investigación adicional.

Entonces necesitas repetir las pruebas para obtener información Adicional Sobre cómo funciona el servidor en el límite de recursos.

3: Determinación del ancho de banda máximo.

En esta etapa, debe usar el software que pueda acelerar la descarga ligeramente para verificar el rendimiento del servidor en niveles diferentes banda ancha. Algunos programas le permiten especificar un retraso entre cada solicitud, pero dificulta la determinación del ancho de banda exacto.

Aquí puede consultar la herramienta WRK2, que le permite especificar el número exacto de solicitudes por segundo.

Tome la velocidad máxima de las solicitudes que ha identificado en la etapa anterior, y divídala en 2. Inicie otra prueba con nuevos datos y preste atención al tiempo de respuesta. ¿Es el indicador en un rango aceptable?

Si es así, aumente el valor al máximo y repita la prueba hasta que el retraso alcance el valor máximo que considere aceptable. Esta será la tasa de respuesta máxima real que su servidor puede procesar.

Herramientas para pruebas de carga

Hay muchos paquetes de software de código abierto para servidores de prueba de carga. Además, hay muchos servicios pagadosque puede crear automáticamente gráficos e informes según los datos obtenidos durante las pruebas. Estos servicios son muy adecuados para sitios grandes que necesitan generar una carga alta para probar una gran infraestructura.

Sin embargo, algunas de las herramientas abiertas también pueden operar en modo de clúster. Considere varias de las herramientas de código abierto más populares.

Herramienta ab

(o ApacheBench) es una herramienta simple de una línea de comandos simples para probar los servidores HTTP. Inicialmente, se diseñó como parte del servidor HTTP de Apache, pero se puede usar para probar cualquier servidor HTTP o HTTPS.

Dado que es un solo roscado, la herramienta AB no puede usar múltiples procesadores para enviar una gran cantidad de solicitudes. No funcionará si desea cargar completamente un poderoso servidor web.

La llamada básica al comando AB se ve así:

aB -N 1000 -C 100 http://example.com/

La bandera -n establece el número de solicitudes. Bandera -s establece la competitividad. Luego, debe especificar la URL a probar. La salida (Extracto de la que se muestra a continuación) indica el número de solicitudes por segundo, Tiempo de solicitud y una lista de tiempo de respuesta de percentiles:

. . .
Solicitudes por segundo: 734.76 [# / sec] (media)

Tiempo por solicitud: 136.098 (media)

Tiempo por solicitud: 1.361 (media, en todas las solicitudes concurrentes)
Tasa de transferencia: 60645.11 recibida
Porcentaje de las solicitudes que se sirven dentro de un tiempo de certiain (MS)
50% 133

66% 135

75% 137

80% 139

90% 145

95% 149

98% 150

99% 151

100% 189 (solicitud más larga)

JMETER.

JMETER es una aplicación potente y multifuncional para pruebas de carga y función de Apache Software Foundation. Las pruebas funcionales son para verificar la salida de la aplicación.

JMeter ofrece una interfaz gráfica Java para configurar los planes de prueba.

Los planes de prueba se pueden escribir utilizando el servidor Proxy JMeter y un navegador regular. Esto le permite usar tráfico en pruebas, lo que imita con mayor precisión el funcionamiento real del servidor.

JMETER puede mostrar información sobre percentiles en informes HTML y otros formatos.

Cerco

Siege es otra herramienta de línea de comandos para pruebas de carga. Parece que ab, pero tiene varias características adicionales. SIEGE: una herramienta multi-roscada que proporciona un rendimiento relativamente alto. También le permite especificar varias URL para pruebas de carga a la vez. La llamada básica se ve así:

sIEGE -C 100 -T 30S http://example.com/

La bandera está indicada por la competitividad. La bandera -t determina la duración de las pruebas (en este caso, 30 segundos). SIEGE Muestra el tiempo promedio de respuesta y la velocidad de solicitud:

. . .
Transacciones: 5810 hits.
Disponibilidad: 100.00%.
Tiempo transcurrido: 29.47 segundos.
Datos transferidos: 135.13 MB
Tiempo de respuesta: 0.01 segs.

Tasa de transacciones: 197.15 TROS / SEC

Rendimiento: 4.59 MB / seg.
Concurrencia: 2.23.
. . .

Siege no proporciona percentiles para las estadísticas de retraso.

Langosta.

La langosta es una herramienta para las pruebas de carga en base basada en Pythonque proporciona una interfaz web para monitorear los resultados en tiempo real.

Los escenarios de prueba de langosta se escriben utilizando el código de Python, que proporciona beneficios adicionales para aquellos que están familiarizados con este lenguaje de programación.

La langosta también se puede iniciar en un modo distribuido: puede iniciar el clúster desde los servidores de LOARID, que creará una carga alta de su servidor. Esto le permite realizar pruebas de carga de alta calidad de toda la infraestructura del servidor web.

LOCUST puede proporcionar estadísticas detalladas en los archivos CSV que se pueden descargar.

Herramienta WRK2.

wRK2 es una herramienta de línea de comandos multi-roscada para la prueba de carga capaz de cargar con una frecuencia dada de las solicitudes. Puede proporcionar estadísticas de demora detalladas y admite scripts en el lenguaje de programación de LUA.

wRK2 es llamado por el comando WRK:

wRK -T4 -C100 -D30S -R100 --Latancency http://example.com/

El parámetro -t determina el número de flujos (en este caso, son 4, aquí debe usar el número de kernels de procesador de su servidor). El parámetro -C indica el número de solicitudes simultáneas (aquí 100). La bandera -d determina la duración de las pruebas (30 segundos). La bandera -R indica la frecuencia de las solicitudes por segundo (100). Una salida de retardo detallada proporcionará la bandera de altancia.

. . .
DISTRIBUCIÓN DE LATENCIA (HDRHISTOGRA - Latencia grabada)
50.000% 5.79ms
75.000% 7.58ms
90.000% 10.19ms
99.000% 29.30ms
99.900% 30.69ms
99.990% 31.36ms
99.999% 31.36ms
100.000% 31.36ms
. . .

Conclusión

En este artículo, consideramos la terminología y los conceptos básicos de las pruebas de carga, familiarizadas con la planificación de la prueba y consideramos algunas de las herramientas abiertas disponibles para las pruebas.

Al definir el rendimiento de la infraestructura, puede usar esta información para intentar mejorar el tiempo de respuesta y reducir la carga en el servidor. Puede decidir a favor de la escala vertical u horizontal. Puede optimizar su configuración del servidor web: cambie el número de conexiones, flujos de trabajo o flujos compatibles. También puede optimizar el almacenamiento en caché de datos de uso frecuente, reducir la carga en la base de datos y el tiempo de consulta.



¿Te gustó el artículo? Compártelo