Test dei tempi di risposta: come misurare le prestazioni delle API

โšก Riepilogo intelligente

Il Response Time Testing (RTT) misura il tempo impiegato da un sistema per rispondere a una richiesta, dal momento in cui l'utente la invia al momento in cui l'applicazione ne segnala il completamento. Questa guida illustra le metriche, le tre soglie piรน importanti e gli strumenti per rilevarle.

  • ๏ธ Definizione di base: Il tempo di risposta copre l'intero ciclo, dall'invio della richiesta al completamento dell'elaborazione.
  • ๐Ÿ“Š Tre parametri: Il tempo di risposta medio, il tempo di risposta di picco e il tasso di errore descrivono congiuntamente il comportamento del sistema.
  • ๐ŸŸข 0.1 secondo: L'esperienza risulta istantanea, senza alcuna interruzione percepita dall'utente.
  • ๐ŸŸก 1 secondo: Il limite massimo per un flusso di pensiero ininterrotto.
  • ๐Ÿ”ด 10 secondi: Il limite dell'attenzione, anche se in pratica gli utenti abbandonano ben prima.
  • ๐Ÿงช Metodo di misurazione: All'interno di uno strumento di test di carico, si puรฒ suddividere un processo aziendale in transazioni di inizio e fine.

Test del tempo di risposta

Cos'รจ il test del tempo di risposta?

Test del tempo di risposta Misura il tempo impiegato da un nodo di sistema per rispondere alla richiesta di un altro. รˆ l'intervallo tra l'arrivo di una richiesta e il completamento del processo corrispondente. Ad esempio, si dispone di un'API e si desidera sapere esattamente quanto tempo impiega per eseguirla e restituire i dati in formato JSON. Il tempo di risposta misura la risposta del server per ogni singola transazione o query.

Il tempo di risposta inizia quando un utente invia una richiesta e termina nel momento in cui l'applicazione dichiara che la richiesta รจ stata completata.

Come misurare il tempo di risposta

Per misurare il tempo di risposta, possiamo utilizzare strumenti di test circondando un importante processo aziendale con transazioni di Inizio e Fine. Un processo aziendale puรฒ essere un'azione o un insieme di azioni che gli utenti eseguono nell'applicazione per completare un'attivitร  aziendale come accedere all'applicazione o acquistare un libro su Amazon.com

Test del tempo di risposta
Test del tempo di risposta

Per lo stesso processo di misurazione del tempo di risposta per un'API, la risposta varierร  leggermente da strumento a strumento. Ecco perchรฉ

  • Passo 1) Metodo di calcolo delle metriche raccolte da ciascuno strumento di test del tempo di risposta dell'API
  • Passo 2) Strumenti Simula il carico e la velocitร  di acquisizione che puรฒ fare la differenza nel tempo di risposta
  • Passo 3) Elementi extra registrati durante il monitoraggio dei carichi degli utenti
  • Passo 4) Le metriche di calcolo raccolte da ciascuno strumento aumentano i tempi di risposta a causa dell'elevato consumo di risorse.
  • Passo 5) L'architettura dei due strumenti potrebbe essere diversa

Tipi di metriche di risposta

Metriche del tempo di risposta Spiegazione
Tempo medio di risposta Il tempo medio di risposta รจ il tempo medio impiegato per ogni richiesta di andata e ritorno. Il tempo medio di risposta include il tempo di caricamento di HTML, CSS, XML, immagini, JavaFile di script, ecc. Pertanto, la media viene influenzata quando nel sistema sono presenti componenti lenti.
Tempi di risposta di picco Il Peak Response Time ci aiuta a trovare componenti potenzialmente problematici. Ci aiuta a trovare tutte le irregolaritร  nel sito web o nel sistema in cui una determinata richiesta non viene gestita correttamente. Ad esempio, potrebbe essere eseguita una query di database di grandi dimensioni che puรฒ influire sul tempo di risposta. Questa query non consente il caricamento della pagina all'ora desiderata.
Tasso di errore Il tasso di errore รจ un calcolo matematico che indica la percentuale di richieste problematiche rispetto al totale delle richieste. Questa percentuale include tutti i codici di stato HTTP che segnalano un errore sul server e le richieste che vanno in timeout.

Tre soglie di tempo di risposta che contano

In qualsiasi report sui tempi di risposta, due dati sono fondamentali:

  • Tempo medio di risposta
  • Tempo di risposta massimo o di picco

Insieme, mostrano quanto tempo aspetta in genere un utente e quanto aspetta l'utente piรน sfortunato.

Di seguito sono riportati i valori chiave degli esempi di test del tempo di risposta

Tempo di risposta Significato
0.1 Seconda รˆ il tempo di risposta piรน preferito. Se il tempo di risposta รจ 0.1, gli utenti percepiscono sempre che l'applicazione o il sistema risponde immediatamente e non avvertono alcuna interruzione.
1.0 Seconda Questo รจ il limite massimo accettato per un'esperienza senza interruzioni. รˆ improbabile che gli utenti avvertano interruzioni, sebbene possano riscontrare un certo ritardo. Un tempo di risposta superiore a 1 secondo potrebbe interrompere l'esperienza dell'utente.
secondi 10 Si tratta di un limite massimo oltre il quale il tempo di risposta supera il limite accettabile. Tuttavia, al giorno d'oggi, se il tempo di risposta supera i 6 secondi, l'utente lascerร  il sito o uscirร  dall'applicazione.

Ove possibile, puntate a un intervallo di tempo compreso tra 0.1 e 1 secondo. Gli utenti si adattano a sistemi piรน lenti, ma la soddisfazione cala drasticamente oltre i 2 secondi circa, e ogni secondo aggiuntivo aumenta il tasso di abbandono.

Strumenti per testare il tempo di risposta

Sono disponibili numerosi strumenti per il test dei tempi di risposta. Due dei piรน utilizzati sono:

1) JMeter

Apache JMeter รจ uno strumento di test del carico open source. รˆ progettato per misurare le prestazioni dei siti Web. Questo strumento di test di carico puรฒ essere utilizzato nella metodologia DevOps.

JMeter

Caratteristiche:

  • JMeter consente di eseguire test di carico e prestazioni per vari tipi di server.
  • Questo strumento di test di carico memorizza i piani di test in formato XML che consente agli utenti di generare il piano di test utilizzando un editor di testo.
  • Lo strumento puรฒ essere utilizzato per eseguire operazioni automatizzate e test funzionali delle applicazioni.

Download link: Apache JMeter download


2) Caricare il corridore

Loadrunner Micro Focus รจ uno strumento di test di carico ampiamente utilizzato. รˆ una delle migliori alternative a JMeter che offre un'interfaccia di monitoraggio e analisi intuitiva con grafici e grafici colorati.

Carica corridore

Caratteristiche:

  • Supporta test continui
  • LoadRunner puรฒ funzionare efficacemente su diversi ambienti aziendali
  • รˆ possibile eseguire piรน script di protocollo con Loadrunner
  • Integrazione con vari strumenti di sviluppo come Di Visual Studio, Jenkins, Selenium, ecc.

Download link: LoadRunner Professional

Come questo test si inserisce nella famiglia dei test di prestazione

Il termine "test di prestazione" รจ un termine generico. Le varianti descritte di seguito differiscono solo per la forma del carico applicato e per la durata del suo mantenimento, motivo per cui vengono spesso confuse tra loro.

Tipo di test Modello di carico Domanda a cui risponde
Test di carico Carico di picco previsto, di breve durata Il sistema raggiunge i suoi obiettivi in โ€‹โ€‹condizioni di traffico di punta normali?
Test da sforzo Aumentato oltre la capacitร  fino al cedimento Dove si rompe e il fallimento viene gestito in modo elegante?
Test delle punte Impennata estrema improvvisa, seguita da una fase di regressione. Riuscirร  a sopravvivere e a riprendersi da uno shock di traffico?
Test di resistenza Carico normale mantenuto per molte ore Le prestazioni si degradano nel tempo?
Test di immersione Carico sostenuto per un periodo prolungato Si sono verificate perdite di memoria o esaurimento delle risorse?
Test di stabilitร  Carico variabile in base alle condizioni Il sistema rimane affidabile al variare delle condizioni?
Test volumetrico Utenti normali, volume di dati molto elevato Riesce a gestire la crescita del database?

I test di resistenza e i test di immersione sono spesso considerati sinonimi. Nell'uso comune, entrambi i tipi di test prevedono il mantenimento di un carico prolungato. Laddove i team li distinguono, i test di resistenza si concentrano sul verificare se i tempi di risposta aumentano nel tempo, mentre i test di stress si concentrano sul consumo di risorse come memoria, handle di file e pool di connessioni. L'esecuzione di uno dei due test fornisce solitamente i risultati di entrambi.

Test dei tempi di risposta: punti chiave

  • Il tempo di risposta รจ il tempo impiegato da un nodo del sistema per rispondere alla richiesta di un altro.
  • Il tempo medio di risposta in test delle prestazioni รจ il tempo medio impiegato per ogni richiesta di andata e ritorno.
  • Il tempo di risposta massimo rivela quali componenti sono potenzialmente problematici.
  • Il tasso di errore รจ un calcolo matematico che mostra la percentuale di richieste di problemi.
  • Tre valori cruciali del tempo di risposta sono: 0.1 secondi, 1.0 secondi e 10 secondi.
  • Due degli strumenti di test del tempo di risposta piรน utilizzati sono JMeter and LoadRunner.

DOMANDE FREQUENTI

La latenza รจ il tempo impiegato da una richiesta per viaggiare sulla rete. Il tempo di risposta include la latenza piรน tutta l'elaborazione e il rendering da parte del server. Anche una rete veloce puรฒ produrre tempi di risposta lenti se il server รจ lento.

La media nasconde i valori anomali. Un sistema con una media di 800 ms e un 95ยฐ percentile di 9 secondi non riesce a soddisfare un utente su venti, e solo il percentile lo rivela.

L'obiettivo รจ di impiegare meno di 1 secondo per le azioni interattive e meno di 2 secondi per il caricamento completo della pagina. Oltre i 3 secondi, il tasso di abbandono aumenta drasticamente, a prescindere da quanto suggerito dal limite teorico di 10 secondi.

Il monitoraggio basato sull'intelligenza artificiale stabilisce una linea di base normale per ciascun endpoint e segnala automaticamente le deviazioni, sostituendo le soglie fisse che generano rumore durante i picchi di traffico previsti.

Sรฌ. I modelli addestrati su dati storici di performance possono segnalare quali modifiche al codice potrebbero rallentare un endpoint. Conferma ogni previsione con un'esecuzione effettivamente misurata.

Riassumi questo post con: