¿Es este escenario una prueba de esfuerzo válida?

Question

Tengo una aplicación de servidor que maneja las solicitudes de los clientes de manera diferente.

Quiero saber cuántos usuarios pueden ser atendidos con una latencia mínima, así que hice una pequeña aplicación de prueba de estrés que simula las solicitudes de los usuarios; al mismo tiempo, otra aplicación supervisa la utilización de la memoria / CPU.

La herramienta de prueba de esfuerzo crea hilos cada segundo donde cada hilo representa a un usuario. Si la prueba de esfuerzo no puede crear un nuevo hilo debido a la falta de recursos, se inicia una nueva instancia de la herramienta de prueba de estrés.

El problema es que cada subproceso escribe en el archivo la latencia para cada solicitud y el número actual de subprocesos en ejecución, por lo que esto causa un problema de E / S, ya que después de unos minutos tiene muchos subprocesos que también deben escribir en el disco este comportamiento no existirá en el escenario real ya que el cliente solo solicita los datos.

¿Cómo puedo superar este problema ya que quiero medir la latencia máxima por usuario?

PS:

Algunas respuestas dicen que se ejecute en una máquina diferente para tener en cuenta la latencia de la red, esta es mi prueba de esfuerzo final. Actualmente estoy haciendo esta prueba en el mismo servidor para encontrar cuántos usuarios son compatibles con una latencia mínima.

Answer 1

No está realmente claro si se trata de una aplicación en red o no. Si está conectado en red, simplemente puede escalar la prueba de estrés robando el escritorio de todos durante el fin de semana para ejecutar la prueba de estrés. Esta puede ser la forma más fácil de escalar la prueba si son solo unas pocas pruebas ad-hoc.

Sin embargo, parece que podría haber algunas mejoras simples. Si se trata de una prueba de esfuerzo de larga duración, en lugar de crear un nuevo subproceso para cada solicitud, puede crear un grupo de subprocesos para trabajar (o incluso más fácil, use el grupo de subprocesos, que se escalará automáticamente). Por lo tanto, definiría una prueba para decir 2000 usuarios, y activaría 2000 hilos que martillaban el servidor. Cada hilo estaría esencialmente en un bucle que realiza la prueba y se repite.

Otro elemento que no está claro es si todos sus hilos están tratando de compartir un solo archivo. Una forma de reducir este cuello de botella sería mantener la información en la memoria hasta que se cierre el programa. O haga girar un hilo de escritor, que es responsable de la escritura del archivo, y todos sus otros hilos le dan información. Si se realiza una copia de seguridad de IO, su hilo de escritor simplemente se mantendrá en la memoria hasta que IO esté disponible, y sus hilos de trabajo pueden continuar martillando el servidor mientras tanto. Solo tenga en cuenta que, debido a la sincronización de subprocesos involucrada, esto puede no escalar bien, por lo que es posible que desee almacenar temporalmente algunas entradas en el subproceso de trabajo y solo sincronizar al subproceso de escritor de archivos una vez cada 100 solicitudes. No creo que esto sea un gran problema ya que no parece que esté rastreando nada más que los tiempos de respuesta.

Editar: Basado en comentario Sugeriría tratar de usar un solo hilo para administrar sus operaciones de E / S en este caso. Todos sus hilos de trabajo en lugar de escribir en un archivo, crearían un objeto con los detalles, y lo pasarían a una cola para que se escribiera en el archivo. Para reducir el bloqueo / desbloqueo, use también una cola dentro del subproceso de trabajo y solo sincronice de vez en cuando. Asegúrate de bloquear cuando intercambies la información en el hilo. Además, tal vez vería el uso de la memoria, ya que esto permitirá que cualquier cosa pendiente se acumule en la memoria. Si esto sigue causando que bloquees io, consideraría escribir menos, o quizás ajustar o agregar un disco duro más rápido.

Answer 2

Si está interesado en la latencia máxima por usuario, ¿por qué no simplemente recopilar esto en el hilo y al detener la prueba que todos los hilos escriban nuestra latencia máxima? También puede hacer estadísticas, calculando mín. / Máx. / Varianza y número de subprocesos / usuarios en ejecución. Tampoco debe actualizar la salida de pantalla. si temes perder datos, escríbelos en el disco con frecuencia.

Los subprocesos son subóptimos haciendo esta prueba para una aplicación cliente / servidor. Al tener solo un número limitado de núcleos, solo muy pocos de los hilos realmente se ejecutan en paralelo, pero obtienen sus tiempos de espera. Es mucho mejor, y también le da algunas cifras sobre la latencia de la red, para comenzar su programa en varios clientes. El software del servidor puede, si puede hacerlo, usar su hardware como lo hará en la configuración final, donde los clientes se ejecutarán en una LAN o WAN.

Obviamente, tendrá un entorno mixto, ya que no puede tener muchas máquinas cliente como simularon los usuarios, pero los escenarios como las llamadas simultáneas desde un hardware independiente aparecerán en una prueba tan estresante como las llamadas no se cuasi serializan a través de la división temporal.