2010-11-02 15 views
9

Tenemos un sitio basado en MySQL que ocasionalmente obtendrá 100K de usuarios en el espacio de 48 horas, todo iniciando sesión en el sitio y realizando compras.Cómo interpretar Siege y/o Apache Bench Results

Estamos intentando simular este tipo de carga utilizando herramientas como Apache Bench y Siege.

Si bien la métrica clave me parece número de usuarios concurrentes, y tenemos los resultados de nuestro informe, todavía nos sentimos como si estuviéramos en la oscuridad.

Lo que quiero preguntar es: ¿Qué tipo de cosas deberíamos estar probando para anticipar este tipo de tráfico?

50 usuarios simultáneos 1000 Veces? 500 usuarios concurrentes 10 veces?

Estamos viendo los errores de DB, los tiempos de espera de apache y los tiempos de respuesta. ¿Qué más deberíamos estar mirando?

Esta es una pregunta vaga y sé que no hay una respuesta "correcta", solo estamos buscando algunas ideas generales sobre cómo determinar lo que nuestra infraestructura puede manejar de manera realista.

¡Gracias de antemano!

Respuesta

1

Lo ideal es que desee modelar su uso para el usuario, pero crear sesiones simultáneas simuladas para 100k usuarios generalmente no se logra fácilmente. La mejor fuente sería verificar los registros de la hora más ocupada y tratar de encontrar una manera de modelar ese nivel de carga.

La base de datos suele ser una pieza fundamental de la infraestructura, por lo que me gustaría registrar el número y la duración de las esperas de bloqueo, así como el número y la duración de las sentencias de db.

Otro elemento clave a tener en cuenta es la longitud de la cola del disco.

Principalmente, el proceso consiste en buscar respuestas lentas en todo el sitio o en páginas específicas y luego centrarse en la causa. El problema más grande para la prueba de carga es que es bastante difícil probar su red y si tiene (como la mayoría de los sitios públicos) un ancho de banda limitado a través de su ISP, eso puede crear un problema de rendimiento que no se refleja en la carga pruebas.

3

Los usuarios simultáneos son sin duda uno de los factores clave, especialmente los que se aplican a los grupos de conexiones de bases de datos, etc. Pero también querrá verificar que la tasa de páginas (páginas/seg) de sus pruebas también esté en el rango esperar. Si el tiempo de reflexión en sus cajas de prueba no es muy alto, puede simular accidentalmente una frecuencia de página mucho más alta (o más baja) que su tráfico real. El tiempo de reflexión es la cantidad de tiempo que el usuario pasa entre las solicitudes de página: leer la página, completar un formulario, etc.

Dependiendo de la información que tenga a mano, esto puede ayudarlo a calcular el número de usuarios simultáneos a simular: Virtual User Calculators

El tiempo de carga de página completo visto por el usuario final suele ser la medida más importante para evaluar el rendimiento del sistema. También querrá buscar las tasas de falla en todas las transacciones. También debe estar atento a las transacciones que nunca se completan. Algunas herramientas de prueba no informan esto muy bien, lo que permite a los usuarios simulados colgar indefinidamente cuando el servidor no responde ... y no informan esta condición. Busque herramientas que indiquen el número de usuarios que esperan en una página o transacción determinada y la cantidad de tiempo promedio que esperan esos usuarios.

En cuanto a las métricas del lado del servidor que se deben buscar, ¿en qué otras tecnologías se basa su aplicación? Querrá ver diferentes cosas para una aplicación .NET en comparación con una aplicación PHP.

Por último, hemos descubierto que es muy útil observar cómo responde el sistema a la carga en aumento, en lugar de mirar solo un nivel de carga. This article entra en más detalles.

Cuestiones relacionadas