Tecnología de desarrollo de pruebas (2): pruebas de estrés
Como se mencionó en el artículo anterior, actualmente existen dos tipos de puestos de prueba y desarrollo en las empresas de Internet. La mayoría de ellos son responsables de las pruebas comerciales y las pruebas automatizadas, pero también desarrollan marcos de prueba y herramientas de eficiencia para ayudar a las pruebas comerciales. Este tipo de puestos de desarrollo de pruebas (principalmente puestos de back-end) generalmente requieren cierta exposición a pruebas de estrés.
Hay muchos artículos en Internet que presentan los conceptos y las diferencias entre pruebas de estrés, pruebas de rendimiento, pruebas de carga y pruebas de estabilidad. Por lo general, no hay tantas distinciones durante el proceso del proyecto. Todos están orientados a objetivos. Generalmente en proyectos reales, se dice que se realiza una prueba de estrés para ver el desempeño, por lo que los conceptos detallados y las diferencias no se ignorarán aquí. Para una mejor comprensión, aquí lo llamamos prueba de estrés y utilizamos los datos de rendimiento obtenidos como prueba de rendimiento y la observación de la estabilidad como prueba de estabilidad.
Lo mismo entre las pruebas de rendimiento y las pruebas de estabilidad es que ambas se realizan utilizando herramientas de pruebas de estrés. Pero los objetivos son diferentes. Las pruebas de rendimiento son obtener el rendimiento máximo del sistema mediante pruebas de estrés o comparar los datos de rendimiento con la versión anterior. La prueba de estabilidad proporciona un flujo continuo estable o cambiante mediante pruebas de presión para observar si hay anomalías cuando el sistema continúa funcionando.
En circunstancias normales, el sistema general primero realiza pruebas de rendimiento para obtener datos de comparación de rendimiento o rendimiento extremo (para proyectos que no son 1.0, los datos de rendimiento generalmente deben compararse con la versión anterior) y luego continúa Tráfico seguro. La prueba de estrés dura más para verificar la estabilidad.
A continuación, presentaremos en detalle cómo realizar pruebas de rendimiento y pruebas de estabilidad.
El primer paso en las pruebas de rendimiento es determinar el objetivo, es decir, por qué se realizan las pruebas de rendimiento y qué objetivos o efectos se quieren conseguir. Por ejemplo, para un sistema que se inicia por primera vez, la prueba de rendimiento es principalmente para obtener los datos de rendimiento extremo del sistema. Por otro ejemplo, cuando el sistema está optimizado y se reemplaza el protocolo RPC o la cola de mensajes, la prueba de rendimiento es; para cuantificar el efecto de optimización del rendimiento de esta optimización del sistema. Además, no todos los proyectos requieren pruebas de rendimiento. Por ejemplo, para un sistema interno, la cantidad de usuarios y el tráfico en sí son muy pequeños y no aumentarán en el futuro, por lo que básicamente no se requieren pruebas de rendimiento.
Si es un proyecto 1.0 desde cero, porque el proyecto aún no se ha lanzado, solo podemos estimar los datos de tráfico en línea según la experiencia, pero si es un proyecto que no es 1.0, podemos recopilarlos; los datos de tráfico en línea actuales. Los datos específicos recopilados son los siguientes (solo como referencia y deben ajustarse de acuerdo con la situación real): 1) La proporción de varios tráficos de solicitudes del sistema o módulo bajo prueba 2) Los qps promedio, pico y mínimo actuales; del sistema o módulo; 3) Método y escala de implementación en línea; 4) El sistema o módulo bajo prueba depende del QPS o la capacidad que puede soportar.
Después de determinar el objetivo y recopilar los datos en línea existentes, es necesario determinar el plan de pruebas de estrés en función del objetivo y los datos existentes. Por ejemplo, cuánta concurrencia o tráfico se utilizará para las pruebas de estrés en cada uno. Etapa, dividida en varias etapas. ¿Cuánto dura cada etapa y qué datos deben observarse y registrarse durante el proceso de prueba de estrés?
Al mismo tiempo, el entorno de la prueba de estrés también debe estar preparado. El entorno de la prueba de estrés debe ser lo más consistente posible con el entorno en línea. Si no se puede lograr, escale proporcionalmente. Por ejemplo, si un sistema consta de dos módulos, A y B, A ha implementado 20 máquinas en línea y B ha implementado 5 máquinas, entonces la prueba de estrés puede implementar 4 máquinas de A y 1 máquina de B. La cantidad de máquinas e instancias es solo un aspecto. Al mismo tiempo, también se debe considerar el rendimiento de la máquina (cantidad de cajas de CPU, memoria, discos, tarjetas de red, etc.), así como la implementación de las partes dependientes. (como base de datos, caché, cola de mensajes, etc.). La idea central de implementar un entorno de pruebas de estrés es utilizar este entorno para reflejar la verdadera situación del entorno en línea.
Para realizar pruebas de estrés, debe tener una herramienta de pruebas de estrés. En términos generales, se pueden encontrar herramientas listas para usar en línea para pruebas de estrés http u otros protocolos de código abierto, como jmater. Pero si el escenario es especial, o se utiliza el protocolo privado de la empresa o proyecto, sólo podrás utilizar las herramientas internas de la empresa o desarrollarlo tú mismo.
Después de seleccionar una herramienta de prueba de estrés, debe construir datos de prueba de estrés. Hay dos puntos principales en la construcción de datos de prueba de estrés:
El primer punto es construir los datos en el sistema del entorno de prueba de estrés. Debido a que debe haber ciertos datos dentro del sistema en línea, si queremos simular en línea tanto como sea posible, debemos agregar los datos correspondientes al sistema.
Otro punto es preparar los datos de la solicitud para las pruebas de estrés. Esto está relacionado con la herramienta de prueba de estrés seleccionada, que generalmente se divide en dos tipos:
1) Las solicitudes de prueba de estrés se preparan con anticipación y se almacenan en archivos, base de datos o caché, y el volumen de datos. es grande. Por lo general, es necesario escribir un programa para generarlo.
2) Generación en tiempo real Aquí es donde la herramienta de prueba de estrés genera aleatoriamente solicitudes en tiempo real en función de las reglas de configuración durante la prueba de estrés.
Con todos los preparativos en marcha, el siguiente paso es iniciar la ejecución de la prueba de estrés. En este momento, lo principal es ajustar el número de concurrencia o solicitudes de la herramienta de prueba de estrés de acuerdo con el plan de prueba de estrés de menor a mayor para realizar pruebas de estrés en el sistema o módulo de destino.
Durante las pruebas de estrés, es necesario observar la CPU, la memoria, la E/S de la red, el espacio en disco, los registros de destino estresados, el estado de los sistemas o módulos dependientes, etc., y también registrar el número de solicitudes procesadas por el sistema o módulo de destino bajo diferentes QPS y tiempo de respuesta. Al mismo tiempo, también debe prestar atención a si hay pérdidas de memoria, pérdidas de manejo, fallas del sistema, etc.
De hecho, algunos datos se pueden ordenar inicialmente durante el proceso de grabación. Aquí necesitamos resumir los datos registrados en el paso anterior, principalmente para producir los datos mencionados anteriormente en diferentes condiciones de concurrencia. Es necesario juzgar el rendimiento extremo en función de los datos, descubrir dónde está el cuello de botella en esta situación de implementación y qué lo causa, a fin de proporcionar una base para la expansión posterior. En algunos casos, es necesario comparar con datos anteriores para ver si la mejora o la disminución del rendimiento están en línea con las expectativas. Finalmente, después de resumir y analizar exhaustivamente esta información, se elabora un informe de prueba de rendimiento.
Por lo general, después de obtener los datos de rendimiento después de las pruebas de rendimiento, las pruebas de estrés continuarán durante un período más largo en condiciones de concurrencia o tráfico seguro para garantizar la estabilidad del servicio. Por ejemplo, cuando normalmente pruebo el rendimiento, cada ronda de pruebas de estrés puede tardar entre media hora y una hora (puede ser más corta cuando la concurrencia o el tráfico es pequeño al principio). Después de obtener el rendimiento límite, controlaré el rendimiento límite. a 80-90 El tráfico o la concurrencia debe probarse durante un período de tiempo más largo. Este tiempo generalmente es más largo y, en la mayoría de los casos, se iniciará antes de salir del trabajo por la noche y luego llegará a la empresa al día siguiente. ver los resultados.
Además de verificar el tráfico seguro durante mucho tiempo, a veces en escenarios especiales, también es necesario verificar si la estabilidad se ve afectada por una caída repentina o repentina del tráfico dentro del rango de tráfico seguro. O verificar si bajo un determinado flujo de tráfico, simulando un problema con una determinada dependencia o módulo dentro del sistema y ejecutando el plan correspondiente, el impacto en el sistema general es el esperado.
Por supuesto, muchos casos de estabilidad son anormales, pero se realizarán más anormalidades en la prueba anormal. La prueba de estabilidad aquí se refiere a la prueba de estabilidad bajo una determinada presión de flujo, y las demás no se analizan. .
Lo anterior presenta qué hacer en la prueba de estrés, la prueba de rendimiento y la prueba de estabilidad, pero ¿cómo hacerlo específicamente? A continuación lo presentaremos brevemente a través de un ejemplo.
? Un sistema de envío de mensajes, los mensajes enviados son los mensajes de notificación de nuestra aplicación móvil diaria. El sistema para esta notificación de mensajes tiene tres interfaces: unidifusión (enviada a una persona específica), multidifusión (enviada a un grupo, puede haber varias personas en el grupo) y transmisión (enviada a todos los usuarios de la aplicación). Ahora este sistema ha sido reestructurado y se ha actualizado el protocolo RPC para interacción interna, así que quiero comprobarlo y compararlo con los datos de rendimiento anteriores. Además, antes de la reconstrucción del sistema, el rendimiento máximo del clúster en línea era de 30.000 QPS.
A continuación, presentaremos brevemente cómo hacerlo según los pasos anteriores.
? El objetivo es obtener los datos de rendimiento del sistema reconstruidos y compararlos con el rendimiento extremo original conocido, que es de aproximadamente 30.000 QPS.
Recopile datos en línea, por ejemplo, recopilamos que la proporción de solicitudes de unidifusión, multidifusión y transmisión es de 5:78:1; la cantidad de personas en el grupo es de aproximadamente 300-1000; Los caracteres del mensaje enviado tienen un rango de 30 a 100.
El plan de prueba de estrés primero debe determinar el plan de implementación. Por ejemplo, este sistema tendrá 20 máquinas (o instancias) y la prueba de estrés utilizará 2 máquinas (escalado igual). La máquina de prueba de presión es 1/10 de la que está en línea, por lo que nuestro rendimiento objetivo es 3000 qps. Entonces nuestro plan de pruebas de estrés se puede configurar de la siguiente manera:
La primera ronda, 2 sesiones simultáneas, de 5 a 10 minutos, el objetivo principal es verificar primero que no haya problemas con el entorno y las herramientas de pruebas de estrés.
En la segunda ronda, según la cantidad de concurrencia y recursos de la máquina (CPU, memoria, IO) en la ronda anterior, ajuste la concurrencia a más de la mitad del límite (por ejemplo, antes de eso); Había 2 concurrencias, la CPU ocupaba aproximadamente 10, memoria, IO La ocupación es muy pequeña, por lo que usamos la ocupación de la CPU como referencia para calcular. Una concurrencia ocupa aproximadamente 5, luego podemos ajustar la concurrencia a 10-12, y la. La ocupación de CPU objetivo es 50-60). Este es en realidad el verdadero comienzo de la prueba de estrés. Si no hay ningún problema, comience a aumentar gradualmente la presión;
En la tercera ronda, comience a aumentar gradualmente, aumentando de 2 a 5 concurrencias a la vez. la situación real, hasta que el desempeño llegue al cuello de botella.
Aquí se supone que la herramienta de prueba de estrés controla la presión ajustando el número de concurrencia. Es principalmente necesario observar el impacto de la concurrencia en la CPU, la memoria y el IO del sistema, y juzgar. cuánta concurrencia aumenta en función de la información de ocupación de recursos de la máquina durante la prueba de esfuerzo.
Después de determinar el plan, debe implementar un entorno de prueba de estrés. Tenga en cuenta que debe intentar utilizar máquinas con la misma configuración que en línea.
Las herramientas de prueba de estrés deben seleccionarse en función del negocio real. Si es necesario, debe desarrollarlas usted mismo. Si existe la oportunidad de presentar el desarrollo de herramientas en otros artículos más adelante, no lo presentaré aquí. . En nuestro ejemplo, debido a que el sistema reemplaza el protocolo interno y la interfaz externa permanece sin cambios, se puede utilizar la herramienta de prueba de estrés original.
Lo siguiente es construir los datos:
Primero, debemos construir los datos dentro del sistema, como información del usuario, información del dispositivo e información del grupo. Esto debe basarse en. la información recopilada en línea para construir, como el número de usuarios, el número de grupos, el número de usuarios en el grupo, etc. Este tipo de datos se puede insertar directamente en la base de datos si es conveniente, o se puede utilizar la API del sistema correspondiente para prepararlos.
Luego están los datos de solicitud de pruebas de estrés. Por ejemplo, la herramienta de pruebas de estrés utiliza un diccionario de datos para realizar pruebas de estrés, por lo que aquí usamos un script para generar los datos de solicitud de pruebas de estrés. Aquí debemos prestar atención a la proporción de cada interfaz recopilada en línea, que es 5:78:1. Durante la prueba de presión, el flujo se proporciona de acuerdo con esta relación.
Se completan los trabajos de preparación y comienza la prueba de presión.
En este momento, primero debe preparar todo tipo de observaciones de datos. Generalmente, las principales empresas de Internet ahora tienen herramientas gráficas para verlos. Si no, también puede verlos a través de algunos comandos de Linux. Los comandos de uso común incluyen top\ps\vmstat. Se recomienda usar top para ver las condiciones de los recursos en tiempo real y usar vmstat para generar regularmente las condiciones de los recursos actuales (vmstat -t 1 significa generar una vez por segundo).
Cuando esté listo para observar, inicie la herramienta de pruebas de estrés y realice las pruebas de estrés de acuerdo con el plan. El plan de pruebas de estrés se presentó anteriormente y no se repetirá aquí.
Si agregamos 20 usuarios simultáneos, el uso de CPU alcanza aproximadamente 85, las solicitudes de procesamiento alcanzan 3600 qps y el uso de otros recursos es menos de la mitad de la máquina; cuando agregamos 22 usuarios simultáneos, el uso de CPU alcanza 95; - 100, la solicitud de procesamiento es 3700 qps, la concurrencia aumenta a 24, la CPU está llena, la solicitud de procesamiento es 3800 qps y aparece un registro de errores. En este momento, puede detener la prueba de esfuerzo.
? Para organizar los datos, primero necesitamos organizar una tabla o ícono. Aquí usamos una tabla:
Esta tabla son los datos centrales producidos por la prueba de esfuerzo, porque la CPU. Obviamente, para los cuellos de botella de rendimiento, otros recursos no se reflejarán en la tabla. Si la tasa de uso de otros recursos es relativamente alta, también deben incluirse en esta tabla, o si el cuello de botella es una dependencia externa, también debe reflejarse. . De estos datos se puede ver que 3700QPS es el límite de procesamiento del sistema y el tráfico seguro es 3600QPS. En este momento, puede utilizar un número de concurrencia de 17 a 20 para realizar una prueba de presión a largo plazo para ver la estabilidad general del sistema.
Entonces, ¿cómo redactar un informe de rendimiento? A continuación se proporciona un ejemplo de informe de rendimiento relativamente simple.
Título: Informe de prueba de rendimiento de actualización del protocolo RPC de envío de mensajes
1. Antecedentes del proyecto
Escriba aquí los antecedentes y los objetivos del proyecto
2 Entorno de prueba de estrés
Hay 20 máquinas físicas en línea. El entorno de prueba de estrés utiliza 2 máquinas físicas. La configuración es consistente con la en línea. Los detalles son los siguientes:
XX. core, memoria XXG, tarjeta de red de 10Gb, disco duro 400G*6 SSD
DB: XX maestro XX esclavo XX copia de seguridad
3. Plan y datos de pruebas de esfuerzo
1. Proporción de solicitudes
? Unicast: Multicast: Broadcast=? 5:78:1
2. Datos del proceso de prueba de esfuerzo
3. ¿Uso de recursos? chart
Puede utilizar una herramienta (como Excel) para generar un gráfico de líneas de QPS y uso de CPU. Además, puede pegar imágenes de datos ocupados por otros recursos.
4. Conclusión
Durante la prueba de esfuerzo, cuando la presión alcanzó 3700qp, la memoria y el IO eran normales, el uso de la CPU alcanzó 98 y no hubo ningún registro de errores. Cuando la presión alcanza los 3800 qps, la CPU está completamente cargada y los registros de errores comienzan a aparecer después de 5 minutos. Por lo tanto, el rendimiento máximo del sistema cuando se implementa en dos máquinas físicas es de 3700 qps y el cuello de botella del rendimiento es la CPU. Se estima que el rendimiento máximo de las 20 máquinas en línea es de 37000 qps.
El protocolo RPC del sistema es. Se actualizó a 30.000 qps en las 20 máquinas antes de la actualización. Después de la actualización, se espera que pueda alcanzar 37.000 qps y el rendimiento general mejoró en 23, en línea con las expectativas.
El informe anterior es relativamente simple. En proyectos reales, el cuello de botella no es necesariamente la CPU, pueden ser otros recursos o pueden ser sistemas o módulos dependientes. Todos estos requieren observación y análisis. datos en la prueba de estrés.
Las pruebas de estrés son una habilidad esencial para los desarrolladores de pruebas y de back-end. Este artículo es solo un resumen de las pruebas de estrés basado en la experiencia del autor. No puede cubrir todos los escenarios de pruebas de estrés y es solo para su referencia. . Lo que necesitamos más es explorar y practicar en función de la situación real del sistema.