Relacionar los tiempos del navegador, la API y la base de datos
Una petición de listado hipotética relaciona los puntos de medición con el identificador de la solicitud para no contar dos veces tiempos ya incluidos.
Una pantalla lenta no demuestra dónde se pierde el tiempo. Un análisis dirigido requiere que desarrollo y operaciones usen la misma tarea, la misma solicitud y límites de medición definidos.
El siguiente ejemplo es completamente hipotético. El identificador req-17, los tiempos y la estructura de consultas son inventados. No se midió ningún sistema cliente.
Delimitar una solicitud concreta
Aquí, un portal carga una lista de pedidos de 20 filas. Estas mediciones supuestas corresponden a la solicitud:
Punto de medición | Duración supuesta | Qué se mide |
|---|---|---|
Navegador | 2400 ms | Carga del recurso API hasta recibir por completo la respuesta |
API | 2300 ms | Procesamiento de la solicitud en el servidor |
Acceso a la base | 2100 ms | Suma de las llamadas a la base ejecutadas sucesivamente durante ese procesamiento |
El tiempo de base de datos está incluido en el del servidor, y este en la carga del recurso. Sumarlos cuenta el mismo tiempo varias veces. En llamadas paralelas, la suma también puede superar el tiempo transcurrido.
No se pueden restar sin más las horas absolutas de inicio del navegador y del servidor sin una referencia temporal adecuada. Use duraciones definidas y una relación trazable con la misma solicitud.
Investigar el tramo destacado
El flujo inventado genera 21 llamadas a la base: una consulta de lista y una de detalle por fila. Ese acceso repetido se convierte en una pista concreta. Un número alto de consultas no demostraría por sí solo esa estructura; aquí forma parte explícita del ejemplo.
Examine qué información necesita realmente la vista. Una consulta conjunta limitada puede ser una modificación posible. Debe devolver los mismos registros permitidos. Esto no justifica cargar todos los datos en una consulta enorme.
El tiempo del navegador termina al recibir el recurso. No demuestra que la vista sea utilizable entonces. Si sigue bloqueada, deben analizarse por separado procesamiento, representación y otros recursos.
Comprobar en condiciones comparables
Registre versión, tarea, volumen, filtros y alcance de permisos. También carga simultánea y estado de caché. Una caché vacía y otra ya llena pueden dar resultados diferentes.
Repita el flujo antes y después del cambio en condiciones adecuadas. Compruebe el resultado y los límites de acceso además del tiempo. Una petición especialmente rápida no basta para demostrar una mejora general.
El acceso a métricas técnicas debe estar controlado; esta nota no necesita contenido de clientes. El análisis debe producir un cambio justificado y delimitado, no un juicio general sobre la velocidad de toda la aplicación.
Fuentes
Seguir leyendo
Todos los artículos
Desarrollo de software con ASES
Software a medida, aplicaciones web y móviles