¿Cómo probar la estabilidad del servidor?
La estabilidad del servidor es lo más importante. Si la estabilidad no puede garantizar las necesidades del funcionamiento empresarial, el alto rendimiento será inútil.
Los fabricantes habituales de servidores probarán la estabilidad operativa de sus productos bajo diferentes temperaturas y humedad. La clave a considerar es la función de redundancia, como por ejemplo: redundancia de datos, honorabilidad de la tarjeta de red, redundancia de la fuente de alimentación, redundancia del ventilador, etc.
Algunos métodos de prueba se dividen principalmente en las siguientes categorías:
Prueba de estrés: conozca el número de usuarios del sistema durante el período pico y verifique que cada transacción opere por debajo del número máximo. de transacciones simultáneas (convertidas por la cantidad de usuarios durante el período pico) El tiempo de respuesta puede cumplir con los requisitos del cliente. Si los indicadores de rendimiento del sistema todavía se encuentran dentro de los valores normales bajo esta presión. Si el sistema provocará reacciones adversas debido a dicha presión (como tiempo de inactividad, suspensión anormal de la aplicación, etc.).
Diseño incremental de aceleración: por ejemplo, si el número de usuarios simultáneos es 75 y el número de usuarios registrados en el sistema es 1500, utilice 5-7 como valor de referencia para los usuarios simultáneos. Generalmente, el diseño de presurización se realiza cargando 5 personas cada 15 segundos. Este valor se refiere principalmente al rendimiento del presurizador de prueba. Se recomienda ejecutarlo varias veces. El método de carga real se mide por la tasa de aprobación de transacciones y la tasa de error.
Objetivo de diseño incremental: encontrar la posición del cuello de botella en el rendimiento del sistema que ha sido presurizado incrementalmente y aprovechar la oportunidad del punto de inflexión del rendimiento. Generalmente, la referencia comúnmente utilizada es Tasa de clics y rendimiento, CPU. y el uso de la memoria. Simule la cantidad de usuarios durante los períodos pico, como iniciar sesión por la mañana, cerrar sesión después del trabajo, el sistema de mensajería al enviar salarios, etc.
Otro método de simulación de límites puede considerarse como un indicador de operación de límite del sistema que hace clic simultáneamente en las operaciones de transacción en condiciones de máxima presión. El método de presurización permanece sin cambios y se establece el mismo nombre de punto de encuentro en cada punto de transacción del script (como: lr_rendzvous ("mismo");). Según el estándar de alcanzar el porcentaje de puntos de encuentro al mismo tiempo, todos los Vusers en ejecución se lanzarán al mismo tiempo.
Prueba de estabilidad: Conocer el número de usuarios del sistema en periodos punta, frecuencia de cada operación de transacción, etc. Diseñe un escenario de prueba integral y ejecute cada escenario en conjunto de acuerdo con un cierto número de personas durante la prueba para simular el uso del usuario durante varios años. Y controlar si los indicadores de rendimiento del sistema pueden mantener valores normales bajo esta presión durante la prueba. ¿El tiempo de respuesta de la transacción fluctuará o aumentará a medida que aumente el tiempo de prueba? Si el sistema experimentará situaciones anormales como tiempo de inactividad y suspensión de aplicaciones durante el período de prueba.
Según la ubicación del punto de inflexión del rendimiento bajo cada condición de transacción en la prueba anterior, se ha determinado el número de usuarios simultáneos para la prueba de estabilidad. Aún basándose en el servidor de prueba real (rendimiento de tres partes del presurizador, el servidor de aplicaciones y el servidor de datos), se estima el número final de usuarios simultáneos.
Ideas de diseño de escenarios:
Desde la perspectiva de la importancia del diseño del escenario de prueba de estabilidad, se debe considerar en varias situaciones:
Tomando el mismo escenario Como ejemplo, lo siguiente toma como ejemplo la carga de documentos adjuntos oficiales para analizar brevemente las ideas de diseño del escenario:
1) Escenario 1: el escenario de prueba está diseñado para usuarios concurrentes que han alcanzado el rendimiento punto de inflexión en el entorno de pruebas de estrés, con el propósito de verificar los indicadores de rendimiento del servidor de pruebas bajo extrema presión.
2) Escenario 2: según la CPU, la memoria y otros indicadores en el entorno de prueba de estrés, seleccione 50 que el servidor pueda soportar la presión máxima para determinar la cantidad de usuarios simultáneos.
Método de prueba: Utilice 1) Incrementar la carga de todos los Vusers simultáneamente
2) Duración: ejecutar indefinidamente
3) Marque Inicializar todos los Vusers en la programación antes Ejecutar
Prueba de tolerancia a fallas: simulando algunas situaciones anormales (como un corte repentino de energía del servidor, red intermitente, espacio insuficiente en el disco duro del servidor, etc.), verifique si el sistema puede funcionar cuando ocurren estas situaciones. Mecanismo de procesamiento automático para garantizar el funcionamiento normal o medidas de recuperación del sistema. Si hay un HA (sistema automático de recuperación ante desastres), se pueden realizar pruebas adicionales específicamente para estos sistemas de protección automática. Verifique si puede activar efectivamente medidas de protección.
Pruebas de eliminación de problemas: basadas en casos originales o juicios empíricos, las pruebas de verificación se llevan a cabo en módulos del sistema donde se han producido problemas o donde se sospecha de peligros ocultos. Verifique que ocurran los mismos problemas de rendimiento con estos módulos. Por ejemplo: el problema de pérdida de memoria del módulo de archivos adjuntos de carga, la optimización del módulo de la libreta de direcciones, el impacto de activar la supervisión del rendimiento de Tivoli en el rendimiento del sistema OA, etc.
Las pruebas de evaluación son pruebas relacionadas que se utilizan para obtener puntos de indicadores clave de rendimiento del sistema. Su objetivo principal no es tener resultados de prueba claros esperados de antemano, sino obtener indicadores de rendimiento en escenarios de estrés específicos a través de pruebas (como el tiempo de respuesta de la transacción, el número máximo de usuarios concurrentes, etc.).
Evaluación del tiempo de transacción de una transacción: actividad de prueba realizada para obtener el tiempo de respuesta de una transacción bajo una presión específica. Al simular varios valores de presión durante los períodos pico de clientes conocidos o los valores de presión que se espera que sean tolerados, se obtiene el tiempo de respuesta de la transacción bajo esta presión.
Evaluar el número máximo de usuarios concurrentes de una transacción: actividad de prueba realizada para obtener el número máximo de usuarios concurrentes que una transacción puede soportar en un entorno de sistema específico. Al simular el entorno real o utilizar directamente el entorno real, evalúe el número máximo de usuarios concurrentes que la empresa puede soportar en este entorno. Los umbrales estándar de juicio deben definirse de antemano (como el tiempo de respuesta, el uso de la CPU, el uso de la memoria, el pico de la tasa de clics, el pico de rendimiento, etc.).
Número máximo de usuarios concurrentes del sistema de evaluación: Actividades de prueba realizadas para obtener el número máximo de usuarios concurrentes que todo el sistema puede soportar. Al analizar previamente el índice de uso y la frecuencia de cada módulo principal del proyecto, se define el índice de cada transacción en el escenario integral y se asigna el número de usuarios simultáneos de cada transacción en un índice. Simule el entorno real o utilice directamente el entorno real para evaluar el número máximo de usuarios concurrentes que el sistema puede soportar en este entorno. El umbral estándar de evaluación está predefinido (como el tiempo de respuesta, el uso de la CPU, el uso de la memoria, se ha producido un pico de tasa de clics, se ha producido un pico de rendimiento, etc.). El estándar de valor se basa en la regla del barril (la transacción con el menor número de transacciones simultáneas es la cantidad de transacciones simultáneas en todo el sistema).
Evalúe el impacto de diferentes volúmenes de datos de bases de datos en el rendimiento: para pruebas con diferentes volúmenes de datos de bases de datos, compare los resultados de las pruebas y analice el impacto del volumen de datos de cada tabla de la base de datos en el rendimiento de las transacciones. Es posible predecir de antemano los peligros ocultos que pueden existir después de que el sistema haya estado funcionando durante mucho tiempo, o cuando los clientes de determinados módulos requieran una gran cantidad de datos.
Prueba de localización de problemas: se han descubierto o se sospecha que existen problemas de rendimiento en el sistema a través de las pruebas anteriores o de operaciones reales del usuario. Se requiere un escenario de prueba receptivo para reproducir el problema o definirlo. Si es posible, vaya directamente al código o módulo que está causando el problema de rendimiento.
Este tipo de prueba prueba principalmente escenarios de script donde ocurren problemas y puede agregar herramientas de descubrimiento y detección, como activar la supervisión del rendimiento de Tivoli, activar la salida de HeapDump, comandos de supervisión de recursos de Linux, etc. Y complementado con pruebas manuales durante el proceso de ejecución del escenario.