Ejemplo de prueba de rendimiento: ajuste de rendimiento y reducción de costos (16)

Ideas de reducción de costos

Dentro de la Empresa A, el estándar de estabilidad empresarial en línea es: cuando se alcanza el TPS aprobado por la empresa, la utilización máxima de la CPU no supera el 60%, que es un estado estable.

En este contexto, el departamento de pruebas llevó a cabo una clasificación unificada y pruebas de rendimiento especiales para algunos sistemas con alto consumo de CPU, con el objetivo de reducir la utilización máxima de CPU de la aplicación probada mediante pruebas de rendimiento y ajustes para cumplir con los requisitos de TPS comerciales. Si la utilización máxima de la CPU disminuye significativamente, reduzca la cantidad de núcleos de CPU de los nodos implementados y vuelva a realizar las pruebas según el escenario empresarial. Si se descubre que la utilización máxima de la CPU sigue siendo inferior al 60 % y no hay ninguna anomalía en el TPS, la cantidad de núcleos de CPU del nodo de implementación del entorno de producción se reducirá para liberar más recursos para la implementación de otros servicios. Junto con los métodos de seguimiento de la producción, si no hay anomalías dentro de un cierto período de tiempo, la reducción de costos se considerará exitosa.

Las ideas específicas se muestran en la figura.

Los pasos de reducción de costos que se muestran en la figura se explican a continuación.

1) Pruebas de estrés de rendimiento: realice pruebas de estrés de alta concurrencia en la aplicación bajo prueba.

2) Evaluación del desempeño: evalúe los posibles puntos de optimización observando los indicadores de desempeño durante el proceso de prueba de desempeño. Los indicadores de rendimiento incluyen TPS, tiempo de respuesta, utilización de CPU, uso de memoria, tiempo de respuesta del código, topología de enlace completo, etc.

3) Análisis de desempeño: incluye las siguientes tres dimensiones.

❑Realizar análisis de puntos de acceso de CPU y análisis de seguimiento de subprocesos para aplicaciones probadas con alto consumo de CPU. Utilice informes visuales para ver los segmentos de código y los ID de subprocesos de las aplicaciones que se ejecutan cuando la utilización de la CPU es alta y realice un análisis en profundidad del código fuente del segmento de código y las pilas de llamadas de subprocesos para localizar la causa raíz de la alta utilización de la CPU.

❑ Para aplicaciones probadas con alto consumo de memoria, a través del análisis de la perspectiva de la memoria, podemos obtener la nueva generación, la antigua generación, GC, la memoria fuera del montón, los objetos de memoria, los objetos de clase y otros indicadores de JVM en un método de bajo costo. Vea indicadores o curvas anormales en tiempo real a través de informes visuales, analice sus correspondientes objetos de memoria y localice la causa raíz.

❑ Para aplicaciones probadas con tiempos de respuesta de código prolongados, a través del análisis de llamadas de submétodos, se utiliza tecnología de mejora de código de bytes en tiempo real para realizar un análisis que requiere mucho tiempo a nivel de microsegundos de las llamadas de submétodos activadas en el código. Después de localizar el segmento de código que consume más tiempo, inicie el análisis del código fuente para ver la lógica del código fuente y localizar la causa raíz.

4) Ajuste del rendimiento: comuníquese con el equipo del proyecto para solucionar los problemas encontrados de CPU, memoria, subprocesos y código.

5) Verificación de reducción de costos: verifique la aplicación optimizada bajo prueba utilizando el mismo escenario y número de concurrencias para garantizar que se mejoren los indicadores de CPU y de memoria de la aplicación bajo prueba. Para la aplicación bajo prueba que se ha confirmado que está optimizada, reduzca las configuraciones de CPU y memoria y luego realice una prueba de rendimiento utilizando el mismo escenario y número de concurrencias para confirmar que los indicadores de rendimiento después de la degradación cumplan con los estándares en línea.

Si los indicadores de aplicación medidos no cumplen con los estándares en línea después de bajar de categoría, comience desde el paso de evaluación del desempeño y realice el análisis nuevamente.

Caso de reducción de costos

Con base en las ideas de reducción de costos anteriores, el proceso real de ajuste del sistema dentro de la Compañía A es el siguiente. 1) Descripción del problema: en un escenario de prueba de estrés de alta concurrencia, el uso promedio de CPU de las aplicaciones en el sistema se muestra en la Figura 10-19. La utilización real de CPU alcanza el 70,07% y la más alta es el 100%.

Figura 10-19 Utilización de CPU de una aplicación 2) Descripción del proceso de posicionamiento: mediante el análisis de puntos calientes en la plataforma de análisis de rendimiento, se descubre que la mayor parte de la CPU se consume en la operación de escalada de la pila de registros. 

Cuadro de análisis de puntos de acceso de CPU

 3) Determine los puntos de riesgo de rendimiento: el aumento frecuente de registros en condiciones de alta concurrencia provocará un consumo excesivo de CPU y afectará la experiencia general de la aplicación.

4) Presentar sugerencias de optimización: desde la perspectiva de las especificaciones de desarrollo, no se recomienda ubicar por número de línea, porque el costo de hacerlo es demasiado alto y desperdicia demasiados recursos. Es mejor utilizar la cadena de registro de salida con precisión signos para aclarar qué párrafo Hay un problema con la lógica del código. Para este caso, en primer lugar, se recomienda eliminar los parámetros %I y %L que imprimen el número de línea. En segundo lugar, elimine la configuración %method o %m. Actualmente, los registros de nivel de depuración, información, advertencia y error utilizan el mismo conjunto de formatos de salida, es decir, la configuración del patrón es la misma. Se recomienda que Debug e Info no imprimir nombres de métodos y números de línea, pero imprimir directamente Advertencia y Error está bien.

5) Efecto de optimización real: al modificar la configuración, el TPS aumentó de 260 transacciones/segundo a 320 transacciones/segundo, un aumento de más del 25%.

6) Efecto de reducción de costos: después de que la configuración del servidor de aplicaciones se reduce en un 50%, los indicadores generales aún cumplen con el valor objetivo.

Supongo que te gusta

Origin blog.csdn.net/seanyang_/article/details/132916193
Recomendado
Clasificación