Attribuire correttamente i tempi di browser, API e database
Una richiesta di elenco ipotetica collega i punti di misura a un identificativo della richiesta, così le durate già incluse non vengono contate più volte.
Una schermata lenta non dimostra dove si perda tempo. Un’indagine mirata richiede che sviluppo e gestione operativa considerino lo stesso compito, la stessa richiesta e limiti di misura chiari.
L’esempio seguente è interamente ipotetico. Identificativo req-17, tempi e struttura delle query sono inventati. Nessun sistema cliente è stato misurato.
Delimitare una richiesta concreta
Qui un portale carica un elenco ordini di 20 righe. Alla richiesta appartengono queste misure ipotetiche:
Punto di misura | Durata ipotizzata | Che cosa si misura |
|---|---|---|
Browser | 2400 ms | Caricamento della risorsa API fino alla ricezione completa della risposta |
API | 2300 ms | Elaborazione della richiesta nel server |
Accesso al database | 2100 ms | Somma delle chiamate eseguite in sequenza durante questa elaborazione |
Il tempo del database è incluso in quello del server, a sua volta incluso nel caricamento. Sommarli conta più volte lo stesso tempo. Per chiamate parallele, la somma può anche superare il tempo trascorso.
Gli orari assoluti di avvio di browser e server non possono essere semplicemente sottratti senza una base temporale adeguata. Usi durate definite e un’associazione ricostruibile alla stessa richiesta.
Esaminare il tratto che emerge
Il flusso inventato genera 21 chiamate al database: una query di elenco e poi una di dettaglio per riga. L’accesso ripetuto diventa così un punto concreto da esaminare. Un numero elevato di query non dimostrerebbe da solo tale struttura; qui è parte esplicita dell’esempio.
Esamini quali informazioni servono davvero alla vista. Un accesso congiunto delimitato può essere una possibile modifica. Deve restituire gli stessi record consentiti. Non ne deriva la necessità di caricare tutti i dati in una query enorme.
Il valore del browser termina quando la risorsa è ricevuta. Non dimostra che la schermata sia già utilizzabile. Se resta bloccata, elaborazione, visualizzazione e altre risorse vanno considerate separatamente.
Verificare in condizioni confrontabili
Registri versione software, compito, volume, filtri e ambito dei permessi. Contano anche carico simultaneo e stato della cache. Una cache vuota e una già popolata possono dare risultati diversi.
Ripeta il flusso prima e dopo la modifica in condizioni adeguate. Verifichi risultato e limiti di accesso oltre al tempo. Una richiesta particolarmente veloce non basta a dimostrare un miglioramento generale.
L’accesso alle metriche tecniche deve essere controllato; questa nota non richiede contenuti dei clienti. L’indagine deve produrre una modifica motivata e delimitata, non un giudizio generale sulla velocità dell’intera applicazione.
Fonti
Continuate a leggere
Tutti gli articoli
Sviluppo software con ASES
Software su misura, app web e mobile