Tesi: Capitolo 9 Load testing

Nono capitolo della mia tesi di laurea, dedicata allo sviluppo di un CMS per gestire un’Azienda di Promozione Turistica, utilizzando Joomla. Per maggiori informazioni, si veda la pagina della tesi.

Analisi del comportamento del sito sottoposto a un carico computazionale elevato

9.1 Introduzione

Esistono due tipi di test di carico che possono essere effettuati su un sito web: stress test e load test. Con stress test si intende un test atto a verificare il comportamento del sito sottoposto ad un carico di lavoro eccessivo.
Il load testing è una valutazione della performance di un sito web sottoposto ad un normale carico di lavoro, previsto in fase di produzione.

9.2 Presentazione del software utilizzato: DieselTest

DieselTest è un software progettato per Windows, distribuito sotto licenza GNU LGPL. Esso permette di effettuare dei test verso siti Web (HTTP e HTTPS), fornendo monitoraggio e rappresentazione grafica dei risultati ottenuti.

Per effettuare un test, occorre registrare lo scenario che verrà utilizzato nella fase operativa. Questa operazione è resa molto semplice dall’interfaccia grafica composta da un browser semplificato.

Registrare un test è semplice come navigare il sito con il browser: il software DieselTest registra le interazioni, gli istanti temporali a cui queste avvengono e li memorizza per poi applicarli identici nel corso del test.

Definiti i passi che devono essere eseguiti dal software di testing, è quindi possibile scegliere altre impostazioni per il test, come il numero degli utenti fittizi da creare, il tempo di testing, il protocollo utilizzato, lo user ramp-up time, ed è possibile anche modificare gli headers.

Vediamo la schermata di impostazione:

schermata di impostazione

Il numero di virtual users determina il numero di utenti fittizi che il programma crea. Il timeout rappresenta il tempo prima che la richiesta inesaudita scada.

Il runtime è il tempo di esecuzione del test. La checkbox “Use recorded think time” permette di utilizzare come think time (tempo impiegato dall’utente per interagire con il sistema) il think time registrato durante la definizione del test.

Lo user ramp-up time è il tempo di attesa prima di creare un nuovo thread (e quindi un nuovo utente che effettua la richiesta). Impostandolo a 0, tutti gli utenti fittizi vengono creati nello stesso istante.

Dopo avere eseguito il test, è possibile visualizzare i risultati in forma di file di testo, in cui è riportato il log delle operazioni, oppure attraverso un grafico in cui sono riportati il numero di utenti contemporanei e il tempo di accesso registrato.

9.3 Testing e Analisi dei risultati ottenuti

L’ambiente di testing è il seguente: un portatile Mac con installato il server Web Apache, collegato via rete LAN Ethernet con un computer client Windows su cui viene eseguito il programma DieselTest.

Il test si è suddiviso in base ai settaggi impostati al software DieselTest.

[N.B.: in tutti i grafici inizialmente il fetch time ha un picco, causato dalla creazione simultanea di molti connessioni. Successivamente la performance si stabilizza.]

Sequenza di interazione 1: Home page -> Eventi -> Selezione evento “Festa di Lecco”
119 richieste HTTP GET

15 Utenti, 2 minuti
15 utenti, 2 minuti

30 utenti, 2 minuti
30 utenti, 2 minuti

45 utenti, 2 minuti
45 utenti, 2 minuti

55 utenti, 1 minuto
55 utenti, 1 minuto

Sequenza di interazione 2: Home page -> Luoghi -> Selezione luogo “Monumento ai caduti”
85 richieste HTTP GET

15 utenti, 2 minuti
15 utenti, 2 minuti

30 utenti, 2 minuti
30 utenti, 2 minuti

45 utenti, 2 minuti
45 utenti, 2 minuti

55 utenti, 2 minuti
55 utenti, 2 minuti

Sequenza di interazione 3: Home Page -> Percorsi guidati -> Itinerario Manzoniano -> Luoghi visitati: Villa Manzoni

112 richieste HTTP GET

15 utenti, 2 minuti
15 utenti, 2 minuti

30 utenti, 2 minuti
30 utenti, 2 minuti

45 utenti, 2 minuti
45 utenti, 2 minuti

55 utenti, 2 minuti
55 utenti, 2 minuti

Nella prima sequenza di interazione il tempo di risposta è in media alto poichè la navigazione prevede l’utilizzo delle pagine gestite da un componente aggiuntivo di Joomla, JEvents, che quindi comporta un maggiore sforzo computazionale. Inoltre, il numero di richieste HTTP è il più elevato.

La seconda sequenza è quella più veloce, per il minor numero di richieste HTTP e perchè il percorso navigazionale interessa il componente principale di Joomla, com_content, molto veloce.

La terza sequenza prevede 112 richieste HTTP ed i tempi di interazione sono molto vicini alla prima sequenza, pur non interessando nessun componente aggiuntivo. Questo perchè il numero delle pagine richieste è aumentato, da 3 a 4.

Tags:
Articoli correlati:

Lascia un commento

Nome (obbligatorio)

Mail (non sarà pubblicata) (obbligatoria)

Sito web

-->