Aplicación web de prueba de carga

Question

Al realizar una prueba de carga en una aplicación web básica, ¿qué controles de cordura realiza usted además del tiempo de respuesta esperado?
¿Es justo pedir el uso máximo de memoria?
¿Qué otros controles haces?

Answer 1

En el servidor

• solicitudes por segundo de la aplicación pueden soportar
• peticiones por segundo que afectó a la base de datos (si los hay, relacionada con el número anterior, pero es útil para tenerlos como cifras por separado)
• ancho de banda Transferido (separados por tipo de medio, si es posible)
• utilización de la CPU
• utilización de memoria

En el cliente

• Tiempo de respuesta
• Peso de la página promedio
• Es el uso de la CPU de alta en cualquier momento
• Ejecutar algo así como YSlow para ver lo que se puede optimizar en la salida para hacerlo más rápido para los usuarios

Las herramientas de prueba de estrés generalmente vienen con la mayoría de estas medidas (excepto para memoria, CPU y databas) e use), como lo hacen YSlow o Firebug en el cliente.

Answer 2

Observamos una amplia variedad de métricas al analizar los resultados de una prueba de carga.

En el servidor, comenzamos con estas principales 4 categorías:

• CPU (% de utilización, cambios de contexto/seg, proceso longitud de la cola)
• memoria (% uso, lecturas de páginas/seg, página escribe/seg)
• ancho de banda (entrantes, salientes, enviar & recibe errores, conexiones #, fallos en la conexión, el segmento retransmite/seg)
• disco (disco I O tiempo /%, tiempo de servicio promedio, longitud de la cola, lee y escribe/seg)

También nos gusta mirar las métricas específicas para el servidor web y el servidor de aplicaciones en uso. Por ejemplo, en IIS observamos los recuentos de conexiones de IIS, las tasas de aciertos de caché y la frecuencia de rotación, etc. En .NET, estaríamos mirando Solicitudes ASP.NET/seg., Tiempo de ejecución de última petición de ASP.NET, Solicitudes actuales de ASP.NET , Solicitudes en cola ASP.NET, tiempo de espera de solicitud de ASP.NET, errores ASP.NET/seg y muchos otros.

En el lado del cliente, estamos mirando principalmente el tiempo de carga total para las páginas, duración y TTFB (tiempo hasta primer byte) para transacciones críticas, uso de ancho de banda, tamaño de página promedio y tasa de fallas. También encontramos dos métricas muy útiles: las llamamos Usuarios en espera y Tiempo de espera promedio. No muchas herramientas las tienen: le informan en cada período de muestreo exactamente cuántos usuarios simulados están en proceso de recuperar un recurso del servidor y cuánto tiempo, en promedio, han estado esperando que llegue el recurso.Nos encontramos con que son poco útiles para

• determinar cuando el servidor ha alcanzado su capacidad
• descubrimiento de que el servidor ha dejado de responder a ciertos tipos de solicitudes (por lo general para ciertos recursos, tales como las que requieren una consulta de base de datos)

Answer 3

Otro buen control de cordura es ejecutar las pruebas durante al menos 24 horas. Hacemos eso porque una aplicación funcionó bien durante unas horas y luego se degradó. Descubierto algunos problemas con tareas programadas, así como la agrupación de conexiones db.

Answer 4

Hay una serie de servicios en línea que pueden hacer este tipo de prueba también. Por supuesto, una de las desventajas de este enfoque es que es más difícil correlacionar los datos del servicio (que es lo que se puede observar externamente) con sus propios datos internos sobre E/S de disco, operaciones de DB, etc. Si termina yendo por esta ruta, le sugiero que busque un proveedor que le otorgue acceso programático a los datos de resultados de la prueba en bruto.