Ahora, la prueba de presión para visitar la página de inicio por sí sola no pasa por la solicitud de middleware
1. Prueba de presión para obtener la clasificación de primer nivel
Aún agregue el grupo de subprocesos como antes, agregue la solicitud http
Después de funcionar de manera estable durante un período de tiempo, vea el informe agregado
Complete el formulario basado en el informe agregado
Abra jvisualvm y descubrió que el gc menor es muy frecuente debido a la pequeña memoria de Eden Park, lo que afecta en gran medida la eficiencia.
2. Prueba de presión para obtener todos los datos de clasificación de tres niveles
Agregar solicitud http
Ver informe agregado
Complete el formulario, el tiempo de respuesta aquí es un poco indignante, el tiempo de respuesta es una referencia, depende principalmente del rendimiento, si usa otra máquina para probar la presión, los datos del resultado serán estándar, aquí es solo como referencia para encontrar el problema.
3. Prueba de presión para obtener todos los contenidos de la página de inicio (además de la clasificación de primer nivel, también incluye los recursos estáticos de la página)
Bajo la siguiente configuración en avanzado
Agregue una solicitud http, lo mismo que la clasificación de primer nivel de las pruebas de estrés
Ver informe agregado
Rellenar el formulario
4. Piense en el plan de optimización
En el artículo anterior, puede ver claramente el impacto del middleware en el rendimiento. Ahora enumero los puntos que causan la pérdida de rendimiento que he aprendido durante tanto tiempo bajo la prueba de presión.
(1) Middleware: cuanto más middleware, mayor es la pérdida de rendimiento, que se desperdicia en la interacción de la red
(2) db: No hace falta decir esto
(3) tymeleaf: la velocidad de renderizado de la plantilla
(4) Recursos estáticos: los recursos estáticos todavía se colocan en el proyecto y también se debe enviar una solicitud a tomcat para obtener
5. Práctica
(1) la caché de plantilla tymeleaf está activada
El almacenamiento en caché de la plantilla tymeleaf se cerró anteriormente, ahora está abierto
No adquiera recursos estáticos
Prueba nuevamente
En comparación con antes, el rendimiento ha aumentado en docenas
Antes eran más de 230, ahora son alrededor de 290
(2) Optimización de la base de datos
Ajustar el nivel de registro, agregar índice
Cada consulta de base de datos anterior se imprimirá, es decir, local, coloque el entorno y cámbielo al nivel de error.
Después de cambiar
Para agregar un índice, usamos el campo parent_cid para consultar la clasificación de primer nivel
Agregar tiempo de consulta de cálculo
@Override
public List<CategoryEntity> findCatelog1s() {
long l = System.currentTimeMillis();
List<CategoryEntity> categoryEntities = this.list(new QueryWrapper<CategoryEntity>().eq("parent_cid", 0));
System.out.println("消耗时间："+(System.currentTimeMillis()-l));
return categoryEntities;
}Agregar índice
Antes de agregar un índice
Después de agregar el índice, todavía es mucho más rápido en promedio.
6. Prueba de presión optimizada
Abrí el caché tymeleaf anterior, ajusté el nivel de registro al error y agregué el índice, y luego volví a probar la solicitud anterior.
Clasificación de primera clase
Clasificación de tres niveles
Datos completos (clasificación de primer nivel + recursos estáticos)
Rellenar el formulario
Se encuentra que además de la adquisición de la cantidad total de datos, se ha mejorado significativamente el rendimiento de otras solicitudes, razón por la cual, la solicitud de recursos estáticos sigue siendo a través de tomcat
Esto implica la separación de nginx dinámico y estático en el próximo artículo.