test stress online examples python database client-server load-testing stress-testing

python - stress - ¿Cómo debo probar/probar la carga de una aplicación de servidor cliente?



locust examples (5)

Desarrollo un sistema basado en bases de datos de cliente-servidor y necesito diseñar una forma de probar el estrés / carga del sistema. Los clientes inevitablemente quieren saber cosas como:

• ¿Cuántos clientes puede soportar un servidor?
• ¿Cuántas búsquedas concurrentes puede soportar un servidor?
• ¿Cuántos datos podemos almacenar en la base de datos?
• Etc.

La clave de todas estas preguntas es el tiempo de respuesta. Necesitamos ser capaces de medir cómo el tiempo de respuesta y el rendimiento se degradan a medida que se introduce nueva carga para poder, por ejemplo, producir algún tipo de gráfico bonito que podríamos lanzar a los clientes para darles una idea del tipo de rendimiento esperado con un determinado Configuración de hardware.

En este momento simplemente sacamos los dedos en el aire y hacemos conjeturas basadas en lo que ya sabemos sobre el sistema por experiencia. A medida que el producto se somete a condiciones más exigentes, sin embargo, esto resulta ser inadecuado para nuestras necesidades futuras.

Me dieron la tarea de idear un método para obtener tales respuestas de una manera significativa. Me doy cuenta de que esta no es una pregunta que cualquiera pueda responder de manera definitiva, pero estoy buscando sugerencias sobre cómo la gente ha trabajado en sus propios sistemas.

Una cosa a tener en cuenta es que tenemos acceso completo a nuestra API de cliente a través del lenguaje Python (cortesía de SWIG), que es mucho más fácil de trabajar que C ++ para este tipo de trabajo.

Así que allí vamos, arrojo esto al piso: ¡realmente me interesa ver qué ideas pueden aportar!

Si te sientes cómodo con las pruebas de codificación en Python, he encontrado que funkload es muy capaz. No dice que su servidor está basado en http, por lo que puede tener que adaptar sus instalaciones de prueba a su propio estilo de cliente / servidor.

Una vez que tenga una prueba en Python, funkload puede ejecutarla en muchos hilos, controlar los tiempos de respuesta y resumir por usted al final de la prueba.

Prueba 1 : conecte y desconecte clientes como loco, para ver qué tan bien maneja el inicio y el final de las sesiones, y qué tanto su servidor sobrevivirá bajo picos, también mientras mide cuántos clientes no se conectan. Eso es muy importante

Prueba 2 : conecte clientes y manténgalos conectados por una semana, haciendo acciones aleatorias (FuzzTest) . Mida el recorrido de ida y vuelta de cada acción. También mantenga un registro del orden de las acciones, porque de esta manera sus "clientes" encontrarán lagunas en sus usos (muy importante y MUY difícil de probar racionalmente).

Prueba 3 y 4 : determine los casos de uso principales para su sistema y escriba los scripts que realizan estas tareas. Luego ejecute varios clientes que realizan la misma tarea (prueba 3), y también varios clientes que realizan tareas diferentes (prueba 4).

Serie: Ahora la otra dimensión que necesita aquí es la cantidad de clientes. Una buena serie sería: 5,10,50,100,500,1000,5000,10000, ...

De esta forma puede obtener datos para cada serie de pruebas con diferentes cargas de trabajo.

¡Felicidades también por SWIGing la API de sus clientes a Python! Esa es una gran manera de preparar las cosas.

Nota: IBM tiene una muestra de pruebas de fuzz en Java , que no está adaptada a su caso, pero le ayudará a diseñar un buen fuzztest para su sistema

Para el rendimiento, busca dos cosas: la latencia (la capacidad de respuesta de la aplicación) y el rendimiento (cuántas operaciones por intervalo). Para la latencia necesita tener un punto de referencia aceptable. Para el rendimiento, debe tener un rendimiento mínimo aceptable.

Estos son puntos de partida. Para decirle a un cliente cuántos xyz puede hacer por intervalo, entonces necesitará conocer la configuración del hardware y el software. Conocer el hardware de producción es importante para obtener cifras precisas. Si no conoce la configuración del hardware, entonces necesita idear una forma de asignar sus cifras desde el hardware de prueba hasta el hardware de producción final.

Sin conocimiento de hardware, entonces realmente solo puedes observar las tendencias en el rendimiento en el tiempo en lugar de absolutos.

Conocer la configuración del software es igualmente importante. ¿Tiene una configuración de servidor en clúster, está equilibrada de carga, hay algo más ejecutándose en el servidor? ¿Puedes escalar tu software o tienes que escalar el hardware para satisfacer la demanda?

Para saber cuántos clientes puede respaldar, debe comprender qué es un conjunto estándar de operaciones. Una prueba rápida es eliminar al cliente y escribir un cliente de código auxiliar y girar tantas veces como sea posible. Haga que cada uno se conecte al servidor. Eventualmente alcanzará el límite de recursos de conexión del servidor. Sin agrupamiento de conexiones o hardware mejor, no puede obtener más que esto. A menudo alcanzarás un problema arquitectónico antes aquí, pero en cualquier caso tienes límites superiores.

Tome esta información y diseñe un script que su cliente pueda representar. Debe asignar el tiempo que tarda su secuencia de comandos para realizar la acción con respecto a cuánto tiempo le llevará al usuario esperado hacerlo. Comience a aumentar sus números como se mencionó anteriormente para llegar al punto donde el aumento en los clientes causa una mayor disminución en el rendimiento.

Hay muchas formas de realizar pruebas de estrés, pero la clave es comprender la carga esperada. Pregúntele a su cliente acerca de sus expectativas. ¿Cuál es la demanda esperada por intervalo? Desde allí puedes calcular cargas superiores.

Puede hacer una prueba de inmersión con muchos clientes que operan continuamente durante muchas horas o días. Puede intentar conectar tantos clientes como pueda tan rápido como pueda para ver qué tan bien maneja su servidor la alta demanda (también un ataque DOS).

Las búsquedas concurrentes se deben realizar a través de las búsquedas de comportamiento estándar que actúan en nombre del cliente o, escribir un script para establecer un semáforo que espere en muchos hilos, luego puede liberarlos todos a la vez. Esto es divertido y castiga tu base de datos. Al realizar búsquedas, debe tener en cuenta las capas de almacenamiento en caché que puedan existir. Debe probar el almacenamiento en caché y sin almacenamiento en caché (en escenarios donde todos realizan solicitudes de búsqueda únicas).

El almacenamiento de la base de datos se basa en el espacio físico; puede determinar el tamaño de fila a partir de las longitudes de campo y la población de datos esperados. Extrapole esto estadísticamente o cree un script de generación de datos (útil para sus escenarios de prueba de carga y debe ser un activo para su organización) y luego asigne los datos generados a los objetos comerciales. Sus clientes se preocuparán por la cantidad de "objetos comerciales" que puedan almacenar, mientras que usted se preocupará por la cantidad de datos sin procesar que puedan almacenarse.

Otras cosas a considerar: ¿Cuál es la disponibilidad esperada? ¿Qué pasa con el tiempo que lleva poner un servidor en línea? La disponibilidad del 99.9% no es buena si lleva dos días volver a conectarse en línea la única vez que se apaga. Por otro lado, una disponibilidad más baja es más aceptable si se tardan 5 segundos en reiniciarse y tienes una caída.

Si tiene el presupuesto, LoadRunner sería perfecto para esto.