¿Conoce todas las preguntas que deben formularse al entrevistar a ingenieros de pruebas de rendimiento?

1. Basado en el acuerdo. El objeto de la prueba de rendimiento es el software de la arquitectura distribuida de red, y el núcleo de la arquitectura distribuida de red es el protocolo de red
2. Multihilo. El cerebro humano tiene un solo subproceso y la CPU de una computadora tiene varios subprocesos. Las pruebas de rendimiento consisten en utilizar tecnología de subprocesos múltiples para simular la carga de múltiples usuarios
3. Simular escenarios reales. El tiempo de acceso del usuario y la frecuencia de acceso no son fijos.

¿Cuáles son las principales preocupaciones de las pruebas de rendimiento?

1. Atención al usuario. Tiempo de respuesta, estabilidad, recuperabilidad
2. Problemas de operación y mantenimiento. Uso de recursos del servidor/base de datos, velocidad de procesamiento del lado del servidor, si el sistema puede soportar 7*24 horas
3. Prueba de atención. El número máximo de usuarios de acceso, el número máximo de procesos comerciales y si los recursos de memoria se pueden recuperar normalmente
4. Problemas de desarrollo. Código: algoritmo, sentencia sql

Describa brevemente el proceso de prueba de rendimiento.

1. Analizar los requisitos de rendimiento. Seleccione los escenarios más utilizados por los usuarios para probar, tales como: inicio de sesión, búsqueda, pedido, etc. Determine los indicadores de rendimiento, tales como: la tasa de aprobación de la transacción es del 100 %, TOP99 % es de 5 segundos, el máximo de usuarios simultáneos es de 1000 y el uso de la CPU y la memoria es inferior al 70 %. 2. Haga un plan de prueba de rendimiento y especifique el tiempo de prueba (generalmente en la
función Después de la estabilización, como después de la primera ronda de prueba) y entorno de prueba y herramientas de prueba
3. Escribir casos de prueba
4. Construir un entorno de prueba y preparar datos de prueba
5. Escribir scripts de prueba de rendimiento
6. Prueba de rendimiento afinación de guiones. Establecer puntos de control, parametrización, asociación, encuentro, transacciones, ajustar el tiempo de reflexión, eliminar scripts redundantes 7.
Diseñar escenarios de prueba, ejecutar scripts de prueba, monitorear datos
8. Analizar resultados de prueba, recopilar conocimientos de embarque de registro relevantes para el desarrollo
9. Regresión de prueba de rendimiento
10 Escribir un informe de prueba

Prueba de rendimiento de jmeter: explicación detallada de 2023 del último proyecto de prueba de rendimiento de jmeter de gran fábrica en todo el proceso, recopilado en silencio, no lo verá más tarde_哔哩哔哩_bilibili https://www.bilibili.com/video/BV1Vu411L77o /?spm_id_from= 333.999.0.0

¿Cómo determinar la carga máxima del sistema?

A través de la prueba de carga, la concurrencia aumenta continuamente. A medida que aumenta el número de concurrencia, varios indicadores de rendimiento cambiarán en consecuencia. Cuando hay un punto de inflexión de rendimiento, por ejemplo, cuando el número de usuarios alcanza un cierto orden de magnitud, la respuesta el tiempo aumenta repentinamente Entonces este punto de inflexión El número correspondiente de usuarios es el número máximo de usuarios que el sistema puede transportar. Jmeter puede usar un temporizador rps o un grupo de hilos de presión de paso.

¿En qué lugares (qué funciones) de su sistema se ha probado el rendimiento?

Seleccione las funciones más utilizadas por los usuarios para realizar pruebas, como: iniciar sesión, buscar, enviar un pedido

¿Cómo se determina el número de usuarios simultáneos?

1) Primero estará en línea por un período de tiempo, y se estimará en función de los datos de acceso de los usuarios recopilados.
2) Se determinará de acuerdo con la demanda, el tiempo de uso pico, la cantidad de usuarios registrados, el tiempo de respuesta única, etc.

¿En qué entorno se realizan sus pruebas de rendimiento?

Cree un entorno de prueba de rendimiento independiente para realizar pruebas

¿Cuándo se realizan las pruebas de rendimiento?

Prueba comparativa: después de la prueba funcional, hágala cuando el sistema esté relativamente estable.
Pruebas de carga: en la oscuridad de la noche, cuando nadie está usando el sistema

¿Cómo analizar los resultados de las pruebas de rendimiento?

Primero verifique la tasa de aprobación de las cosas y luego analice otros indicadores de rendimiento, como confirmar si el tiempo de respuesta, la tasa de aprobación de la transacción, la CPU y otros indicadores cumplen con los requisitos; si los resultados de la prueba no son creíbles, analice la causa de la excepción y volver a probar después de la modificación

¿Cuál es el papel de think_time?

Simule el tiempo de reflexión del usuario en puntos de referencia comerciales

Después de confirmar que los resultados de la prueba de rendimiento son creíbles, si se encuentran los siguientes problemas, ubique los problemas de acuerdo con las ideas proporcionadas a continuación.

Pregunta 1: El tiempo de respuesta no está a la altura del estándar.
Verifique si el tiempo consumido por la transacción es principalmente en la transmisión de la red o en el servidor. Si es la red, use el gráfico Throughput (rendimiento de la red) para calcular si hay un cuello de botella en el ancho de banda. Si hay un cuello de botella, considere aumentar el ancho de banda. O comprima la transmisión de datos; si no hay cuello de botella, entonces puede ser causado por la inestabilidad de la red. Si el tiempo principal se gasta en el servidor, es necesario verificar la CPU del servidor web y el servidor de la base de datos por separado, y si el uso de la memoria es demasiado alto, porque la CPU y la memoria altas definitivamente harán que el tiempo de respuesta sea demasiado tiempo. Si es un problema con el servidor web, elimine el registro de operación del usuario correspondiente al servidor web y envíelo a la ubicación de desarrollo; si es un problema con la base de datos, elimine el registro correspondiente del servidor de la base de datos y envíelo a la ubicación de desarrollo.

Pregunta 2: Los indicadores de la CPU del servidor son anormales
1: Preste atención a la utilización y la carga de la CPU. Si la utilización es demasiado baja y la carga es demasiado alta, entonces puede haber demasiadas colas de procesos, lo que provoca el bloqueo 2: Preste atención al cambio de
contexto Si hay demasiados conmutadores activos, entonces puede ser un cuello de botella de memoria/E/S; si hay demasiados conmutadores pasivos, es posible que el intervalo de tiempo no sea suficiente, puede considerar ajustar la prioridad del proceso para aumentar el intervalo de tiempo

Problema 3: Sin memoria, el proceso desaparece

1: observe si la asignación de espacio entre la generación joven y la generación anterior de la memoria del montón es razonable y ajuste los parámetros de la memoria
2: si el espacio de intercambio es insuficiente, activando el oomkiller

Pregunta 4: El programa se agota gravemente cuando se ejecuta con varios usuarios, e incluso indica que no puede conectarse al servidor.

El programa puede ser un mecanismo de procesamiento de un solo subproceso, y todos los subprocesos están esperando en línea

Pregunta 5: ¿Cómo identificar los cuellos de botella del sistema?

1: A medida que aumenta la carga, si el rendimiento puede continuar aumentando constantemente y encontrar el punto donde el rendimiento disminuye
2: A medida que aumenta la carga, si el tiempo de respuesta comienza a ser más largo y encontrar el punto donde el tiempo de respuesta de repente
3: ¿Empieza a aparecer el error a medida que aumenta la carga ?

¿Cuáles son los modelos de presión comunes?

1. Modo de concurrencia (modo de usuario virtual)
La concurrencia se refiere a la cantidad de usuarios virtuales concurrentes.Desde una perspectiva comercial, también puede entenderse como la cantidad de usuarios en línea simultáneos. Desde la perspectiva del cliente, para averiguar la cantidad de usuarios en línea que cada nodo del sistema comercial puede llevar al mismo tiempo, puede usar este modo para establecer la concurrencia objetivo, es decir, la cantidad de hilos en el jmeter herramienta 2, modo RPS (modo de rendimiento) RPS (Solicitudes por
segundo
) es el número de solicitudes por segundo. El modo RPS es el "modo de rendimiento". Al establecer el número de solicitudes enviadas por segundo, desde la perspectiva del servidor, la capacidad de rendimiento del sistema se mide directamente.

¿Cuáles son las áreas de aplicación de las pruebas de rendimiento?

Verificación de capacidad: demuestre la capacidad esperada de su sistema a través de resultados de pruebas reales.
Análisis de cuellos de botella: descubra cuellos de botella en el rendimiento del sistema (simultaneidad, carga, presión, recuperación de fallas) a través de una serie de métodos de prueba.
Ajuste de rendimiento: optimice el sistema a través de una serie de medios técnicos. Rendimiento , incluido el tiempo de respuesta, el rendimiento, la utilización de recursos.
Planificación de la capacidad: para cumplir con las expectativas de planificación futuras (número de usuarios, cuota de mercado), realice los ajustes correspondientes en los recursos.

¿Cómo jmeter diseña escenarios de prueba de rendimiento?

Prueba de simultaneidad: grupo básico de subprocesos (énfasis en la simultaneidad por unidad de tiempo, no hay simultaneidad absoluta)
Prueba comparativa: compare repetidamente los resultados para verificar si se pasan los resultados de ajuste (si se mejora tps y se reduce el tiempo de respuesta)
Prueba de carga: continuamente aumentar la carga, descubrimiento de cuellos de botella de rendimiento (grupo de subprocesos de presión de escalera, grupo de subprocesos de concurrencia)
Carga de modo de usuario simultáneo: aumento del número de usuarios simultáneos, descubrimiento de cuellos de botella
Carga de modo de rendimiento: aumento de solicitudes por segundo (rps) para ejercer presión en el servidor, Prueba de estrés de cuello de botella de Discovery tps
:
prueba de estrés de estabilidad de carga continua en el punto de cuello de botella de tps: tps mantiene alta presión y estabilidad. En general, tome el 80 % del tps máximo y continúe ejecutando
la prueba de estrés destructiva: el propósito es solo necesitar una excepción en el lado del servidor
Prueba de recuperación de fallas: después de que ocurre una excepción, el sistema puede recuperarse rápidamente
Prueba de planificación de capacidad: 500,000, 2 horas durante las horas pico

¿Cuáles son las razones por las que tps no puede aumentar?

1. Ancho de banda de la red
En la prueba de estrés, a veces se debe simular una gran cantidad de solicitudes de usuarios.Si los paquetes de datos transmitidos por unidad de tiempo son demasiado grandes y exceden la capacidad de transmisión del ancho de banda, generará competencia por los recursos de la red, lo que resultará en solicitudes recibidas por el servidor El número no alcanza el límite superior de la capacidad de procesamiento del servidor.

2.
La cantidad de conexiones disponibles en el grupo de conexiones es demasiado pequeña, lo que hace que las solicitudes esperen. Los grupos de conexiones generalmente se dividen en grupos de conexiones de servidores (como Tomcat) y grupos de conexiones de bases de datos (o entendidos como el número máximo de conexiones permitidas).

3.
Si la asignación de memoria en montón de GC no es razonable, generará gc frecuentes y gc provocará la suspensión del subproceso. Especialmente fullgc, que hará que el hilo se detenga durante mucho tiempo.

4.
Cuando la base de datos está configurada con alta concurrencia, si los datos solicitados deben escribirse en la base de datos y varias tablas, el número máximo de conexiones a la base de datos no es suficiente, o el SQL para escribir datos no tiene índice, o hay no hay separación maestro-esclavo, la separación de lectura y escritura conducirá a un procesamiento lento de las transacciones de la base de datos y afectará al TPS.

6. Los recursos de hardware
incluyen CPU (configuración, uso, etc.), memoria (ocupación, etc.), disco (E/S, paginación, etc.)

7. Presione
La capacidad de carga de una sola máquina es limitada.Si el número de solicitudes de usuario para simular excede su límite de carga, el TPS se verá afectado (en este momento, se requieren pruebas de presión distribuida para resolver el problema)