Suggerimenti JMeter

JMeter è un popolare strumento open source per il test di carico, con molte utili funzionalità di modellazione come il gruppo di thread, il timer e gli elementi del campionatore HTTP. Questo articolo integra il Manuale dell'utente di JMeter e fornisce linee guida per l'utilizzo di alcuni degli elementi di modellazione JMeter per sviluppare uno script di test di qualità.

Questo articolo affronta anche una questione importante in un contesto più ampio: specificare requisiti precisi in termini di tempo di risposta e convalidare i risultati dei test. Nello specifico, viene applicato un metodo statistico rigoroso, l'analisi dell'intervallo di confidenza.

Si noti che presumo che i lettori conoscano le basi di JMeter. Gli esempi di questo articolo sono basati su JMeter 2.0.3.

Determina il periodo di avvio di un gruppo di thread

Il primo ingrediente nel tuo script JMeter è un gruppo di thread, quindi esaminiamolo prima. Come mostrato nella Figura 1, un elemento Thread Group contiene i seguenti parametri:

  • Numero di thread.
  • Il periodo di accelerazione.
  • Il numero di volte per eseguire il test.
  • All'avvio, se il test viene eseguito immediatamente o attende fino a un orario pianificato. In quest'ultimo caso, l'elemento Thread Group deve includere anche l'ora di inizio e di fine.

Ogni thread esegue il piano di test indipendentemente dagli altri thread. Pertanto, un gruppo di thread viene utilizzato per modellare utenti simultanei. Se la macchina client che esegue JMeter non dispone di una potenza di calcolo sufficiente per modellare un carico pesante, la funzione di test distributivo di JMeter consente di controllare più motori JMeter remoti da una singola console JMeter.

Il periodo di avvio indica a JMeter la quantità di tempo per la creazione del numero totale di thread. Il valore predefinito è 0. Se il periodo di avvio non viene specificato, ovvero, il periodo di avvio è zero, JMeter creerà immediatamente tutti i thread. Se il periodo di avvio è impostato su T secondi e il numero totale di thread è N, JMeter creerà un thread ogni T / N secondi.

La maggior parte dei parametri di un gruppo di thread sono autoesplicativi, ma il periodo di avvio è un po 'strano, poiché il numero appropriato non è sempre ovvio. Per prima cosa, il periodo di avvio non dovrebbe essere zero se si dispone di un numero elevato di thread. All'inizio di un test di carico, se il periodo di avvio è zero, JMeter creerà tutti i thread contemporaneamente e invierà le richieste immediatamente, saturando così potenzialmente il server e, cosa più importante, aumentando in modo ingannevole il carico. In altre parole, il server potrebbe sovraccaricarsi, non perché la frequenza di accesso media è alta, ma perché si inviano simultaneamente le prime richieste di tutti i thread, causando un insolito tasso di successo iniziale. È possibile vedere questo effetto con un listener di report aggregato JMeter.

Poiché questa anomalia non è desiderabile, la regola pratica per determinare un ragionevole periodo di accelerazione è mantenere il tasso di successo iniziale vicino al tasso di successo medio. Ovviamente, potrebbe essere necessario eseguire il piano di test una volta prima di scoprire un numero ragionevole.

Allo stesso modo, anche un ampio periodo di accelerazione non è appropriato, poiché il carico di picco può essere sottostimato. Cioè, alcuni thread potrebbero non essere nemmeno iniziati, mentre alcuni thread iniziali sono già terminati.

Allora come verificare che il periodo di accelerazione non sia né troppo piccolo né troppo grande? Innanzitutto, indovina il tasso di successo medio e quindi calcola il periodo di accelerazione iniziale dividendo il numero di thread per il tasso di successo ipotizzato. Ad esempio, se il numero di thread è 100 e la frequenza di hit stimata è di 10 hit al secondo, il periodo di avvio ideale stimato è 100/10 = 10 secondi. Come si ottiene una stima del tasso di successo? Non esiste un modo semplice. Devi solo eseguire lo script di test una volta prima.

In secondo luogo, aggiungi un listener Report aggregato, mostrato nella Figura 2, al piano di test; contiene il tasso medio di successo di ogni singola richiesta (campionatori JMeter). Il tasso di successo del primo campionatore (ad esempio, una richiesta HTTP) è strettamente correlato al periodo di avvio e al numero di thread. Regolare il periodo di accelerazione in modo che il tasso di successo del primo campionatore del piano di test sia vicino al tasso di successo medio di tutti gli altri campionatori.

Terzo, verificare nel log di JMeter (situato in JMeter_Home_Directory / bin) che il primo thread che termina effettivamente finisca dopo l'avvio dell'ultimo thread. La differenza di orario tra i due dovrebbe essere quanto più lontana possibile.

In sintesi, la determinazione di un buon tempo di accelerazione è regolata dalle seguenti due regole:

  • Il tasso di successo del primo campionatore dovrebbe essere vicino al tasso di successo medio di altri campionatori, prevenendo così un breve periodo di accelerazione
  • Il primo thread che finisce finisce effettivamente dopo l'inizio dell'ultimo thread, preferibilmente il più lontano possibile, prevenendo così un lungo periodo di accelerazione

A volte le due regole sono in conflitto tra loro. Cioè, semplicemente non riesci a trovare un periodo di accelerazione adatto che superi entrambe le regole. Un piano di test banale di solito causa questo problema, perché, in un piano di questo tipo, mancano abbastanza campionatori per ogni thread; quindi, il piano di test è troppo breve e un thread termina rapidamente il suo lavoro.

L'utente pensa a tempo, timer e server proxy

Un elemento importante da considerare in un test di carico è il tempo di riflessione, ovvero la pausa tra richieste successive. Diverse circostanze causano il ritardo: l'utente ha bisogno di tempo per leggere il contenuto, o per compilare un modulo, o per cercare il collegamento giusto. La mancata considerazione del tempo di riflessione porta spesso a risultati dei test seriamente distorti. Ad esempio, la scalabilità stimata, ovvero il carico massimo (utenti simultanei) che il sistema può sostenere, apparirà bassa.

JMeter fornisce una serie di elementi timer per modellare il tempo di riflessione, ma rimane ancora una domanda: come determinare un tempo di riflessione appropriato? Fortunatamente, JMeter offre una buona risposta: l'elemento JMeter HTTP Proxy Server.

Il server proxy registra le tue azioni mentre navighi in un'applicazione Web con un normale browser (come FireFox o Internet Explorer). Inoltre, JMeter crea un piano di test durante la registrazione delle tue azioni. Questa funzione è estremamente conveniente per diversi scopi:

  • Non è necessario creare manualmente una richiesta HTTP, in particolare quei noiosi parametri del modulo. (Tuttavia, i parametri non inglesi potrebbero non funzionare correttamente.) JMeter registrerà tutto nelle richieste generate automaticamente, inclusi i campi nascosti.
  • Nel piano di test generato, JMeter include tutte le intestazioni HTTP generate dal browser per te, come User-Agent (ad esempio, Mozilla / 4.0) o AcceptLanguage (ad esempio, zh-tw, en-us; q = 0.7, zh- cn; q = 0,3).
  • JMeter può creare timer a tua scelta, dove il tempo di ritardo è impostato in base al ritardo effettivo durante il periodo di registrazione.

Vediamo come configurare JMeter con la funzione di registrazione. Nella console JMeter, fare clic con il pulsante destro del mouse sull'elemento WorkBench e aggiungere l'elemento HTTP Proxy Server. Notare che si fa clic con il pulsante destro del mouse sull'elemento WorkBench, non sull'elemento Piano di test, perché la configurazione qui è per la registrazione, non per un piano di test eseguibile. Lo scopo dell'elemento HTTP Proxy Server è di configurare il server proxy del browser in modo che tutte le richieste passino attraverso JMeter.

Come illustrato nella Figura 3, è necessario configurare diversi campi per l'elemento HTTP Proxy Server:

  • Porta: la porta di ascolto utilizzata dal server proxy.
  • Controller di destinazione: il controller in cui il proxy memorizza i campioni generati. Per impostazione predefinita, JMeter cercherà un controller di registrazione nel piano di test corrente e memorizzerà i campioni lì. In alternativa, è possibile selezionare qualsiasi elemento del controller elencato nel menu. Di solito, l'impostazione predefinita va bene.
  • Raggruppamento: come si desidera raggruppare gli elementi generati nel piano di test. Sono disponibili diverse opzioni e la più sensata è probabilmente "Memorizza solo il primo campionatore di ogni gruppo", altrimenti verranno registrati anche gli URL incorporati in una pagina come quelli per le immagini e i JavaScript. Tuttavia, potresti provare l'opzione predefinita "Non raggruppare campioni" per scoprire cosa crea esattamente JMeter per te nel piano di test.
  • Pattern da includere e Pattern da escludere: aiutano a filtrare alcune richieste indesiderate.

Quando si fa clic sul pulsante Start, il server proxy si avvia e inizia a registrare le richieste HTTP che riceve. Ovviamente, prima di fare clic su Start, è necessario configurare l'impostazione del server proxy del browser.

È possibile aggiungere un timer come figlio dell'elemento HTTP Proxy Server, che indicherà a JMeter di aggiungere automaticamente un timer come figlio della richiesta HTTP che genera. JMeter memorizza automaticamente il ritardo di tempo effettivo in una variabile JMeter chiamata T, quindi se aggiungi un timer casuale gaussiano all'elemento HTTP Proxy Server, dovresti digitare $ {T} nel campo Constant Delay, come mostrato nella Figura 4. Questo è un'altra comoda funzionalità che ti fa risparmiare molto tempo.

Notare che un timer fa ritardare i campionatori interessati. Ovvero, le richieste di campionamento interessate non vengono inviate prima che sia trascorso il tempo di ritardo specificato dall'ultima risposta ricevuta. Pertanto, è necessario rimuovere manualmente il timer generato dal primo campionatore poiché il primo campionatore di solito non ne ha bisogno.

Prima di avviare il server proxy HTTP, è necessario aggiungere un gruppo di thread al piano di test e quindi, al gruppo di thread, aggiungere un controller di registrazione, in cui verranno archiviati gli elementi generati. Altrimenti, quegli elementi verranno aggiunti direttamente a WorkBench. Inoltre, è importante aggiungere un elemento HTTP Request Defaults (un elemento Configuration) al controller di registrazione, in modo che JMeter lasci vuoti i campi specificati dai valori predefiniti della richiesta HTTP.

Dopo la registrazione, arrestare il server proxy HTTP; fare clic con il pulsante destro del mouse sull'elemento Controller di registrazione per salvare gli elementi registrati in un file separato in modo da poterli recuperare in seguito. Non dimenticare di ripristinare le impostazioni del server proxy del tuo browser.

Specificare i requisiti di tempo di risposta e convalidare i risultati dei test

Sebbene non sia direttamente correlato a JMeter, la specifica dei requisiti di tempo di risposta e la convalida dei risultati dei test sono due attività critiche per i test di carico, con JMeter che è il ponte che li collega.

Nel contesto delle applicazioni Web, il tempo di risposta si riferisce al tempo trascorso tra l'invio di una richiesta e la ricezione dell'HTML risultante. Tecnicamente, il tempo di risposta dovrebbe includere il tempo necessario al browser per eseguire il rendering della pagina HTML, ma un browser in genere visualizza la pagina pezzo per pezzo, riducendo il tempo di risposta percepito. Inoltre, in genere, uno strumento di test di carico calcola il tempo di risposta senza considerare il tempo di rendering. Pertanto, ai fini pratici del test delle prestazioni, adottiamo la definizione sopra descritta. In caso di dubbio, aggiungere una costante al tempo di risposta misurato, diciamo 0,5 secondi.

Esiste una serie di regole ben note per determinare i criteri del tempo di risposta:

  • Gli utenti non notano un ritardo inferiore a 0,1 secondi
  • Un ritardo inferiore a 1 secondo non interrompe il flusso di pensiero dell'utente, ma si nota un certo ritardo
  • Gli utenti aspetteranno comunque la risposta se viene ritardata di meno di 10 secondi
  • Dopo 10 secondi, gli utenti perdono la concentrazione e iniziano a fare qualcos'altro

Queste soglie sono ben note e non cambieranno poiché sono direttamente correlate alle caratteristiche cognitive degli esseri umani. Anche se dovresti impostare i tuoi requisiti di tempo di risposta in base a queste regole, dovresti anche adattarli alla tua particolare applicazione. Ad esempio, la homepage di Amazon.com rispetta le regole di cui sopra, ma poiché preferisce un aspetto più stilistico, sacrifica un po 'di tempo di risposta.

A prima vista, sembrano esserci due modi diversi per specificare i requisiti del tempo di risposta:

  • Tempo medio di risposta
  • Tempo di risposta assoluto; ovvero, i tempi di risposta di tutte le risposte devono essere inferiori alla soglia

Specificare i requisiti di tempo medio di risposta è semplice, ma il fatto che questo requisito non tenga conto della variazione dei dati è preoccupante. E se il tempo di risposta del 20 percento dei campioni fosse più di tre volte la media? Notare che JMeter calcola il tempo di risposta medio e la deviazione standard per te nel listener Risultati grafici.

D'altra parte, il requisito del tempo di risposta assoluto è piuttosto rigoroso e statisticamente non pratico. E se solo lo 0,5 percento dei campioni non avesse superato i test? Di nuovo, questo è correlato alla variazione del campionamento. Fortunatamente, un metodo statistico rigoroso considera la variazione del campionamento: l'analisi dell'intervallo di confidenza.

Rivediamo le statistiche di base prima di andare oltre.

Il teorema del limite centrale

Il teorema del limite centrale afferma che se la distribuzione della popolazione ha media μ e deviazione standard σ, allora, per n sufficientemente grande (> 30), la distribuzione campionaria della media campionaria è approssimativamente normale, con media μ media = μ e deviazione standard σ media = σ / √n.

Si noti che la distribuzione della media di campionamento è normale. La distribuzione del campione stesso non è necessariamente normale. Cioè, se esegui lo script di test molte volte, la distribuzione dei tempi di risposta medi risultanti sarà normale.

Le figure 5 e 6 seguenti mostrano due distribuzioni normali. Nel nostro contesto, l'asse orizzontale è la media di campionamento del tempo di risposta, spostato in modo che la media della popolazione sia all'origine. La Figura 5 mostra che il 90 percento delle volte le medie di campionamento rientrano nell'intervallo ± Zσ, dove Z = 1,645 e σ è la deviazione standard. La Figura 6 mostra il caso del 99 percento, dove Z = 2,576. Per una data probabilità, diciamo il 90 percento, possiamo cercare il valore Z corrispondente con una curva normale e viceversa.