Design experimental e ANOVA analysis

Introduzione

Lo scopo di un "Experimental Design" è ottenere massime informazioni sul sistema con il minimo numero di esperimenti, una corretta analisi aiuta a separare gli effetti dei vari fattori sulle performance ed a determinare se un fattore ha effetti determinanti o se le differenze osservate tra una osservazione ed un un'altra sono dovute ad errori di misura ed/o parametri non controllati. L'analisi ANOVA ci aiuta a determinare quanto è significativa la variazione dovuta a un fattore rispetto alla variazione dovuta all'errore.

Si vogliono dunque valutare quali sono i fattori che influenzano maggiormente il throughput ed il responseTime di un serverWeb. Il serverWeb sotto analisi è un server WebApache 2 residente su una macchina Ubuntu 10.04. Si ha a disposizione un testbed composto da due macchine virtuali generate e simulate tramite il software VMWare: sulla prima, chiamata UbuntuServer, si è installato il server Apache, mentre la seconda, UbuntuClient, ospita il software httperf, un tool open source per la misurazione del throughput e del tempo di risposta del server; le due macchine sono connesse ad un'infrastruttura LAN virtualizzata dallo stesso VMWare. Obiettivo dell'analisi è individuare quale tra i seguenti fattori: RequestRate, Num-call e FileSize maggiormente influenza le prestazioni del server.

Per effettuare le analisi si utilizzare il tools DOE del software Jmp.

Configurazione della macchina server

Poiché i test richiederanno che il server possa accettare molte richieste su una singola connessione TCP, secondo il modello di HTTP 1.1, è necessario configurare opportunamente Apache: la configurazione di default, infatti, non consente ad esso di ricevere un numero elevato di richieste su una stessa connessione. Il parametro in questione, contenuto in /etc/apache2/apache2.conf è MaxKeepAliveRequests: esso viene settato a un valore molto elevato, ad esempio 100000, in modo che il server accetti al più 100000 richieste su una stessa socket.

Nello stesso file di configurazione, si seleziona la porta 8080 come porta di ascolto del server.

Configurazione della machina client

Httperf è un software open source sviluppato da HP per la misurazione delle prestazioni di un server Web: esso genera un flusso di richieste HTTP verso una particolare risorsa gestita dal server e, collezionando le risposte di quest'ultimo, ne calcola il throughput e il tempo di risposta; l'utente, tramite le opzioni del comando httperf, può selezionare

. il rate di connessioni TCP aperte (opzione --rate)

. il numero di richieste HTTP inviate su ogni connessione (opzione --num-call)

. il numero totale di connessioni eseguite durante il test (opzione --num-conn), utile per specificare la durata totale del test

Vi sono dei limiti all'impostazione del rate di connessioni di cui bisogna tenere conto( [1]):

. il numero di connessioni concorrenti aperte dal client è limitato dal numero di porti disponibili sullo stesso; esclusi i porti riservati, httperf può utilizzarne circa 60000; dato che le socket TCP, dopo la chiusura della connessione, permangono in uno stato TIME_WAIT per circa un minuto, non è possibile aprire più di 1000 connessioni al secondo;

. per ogni connessione aperta, httperf richiede un file descriptor al sistema operativo; il numero di file descriptor che ciascun processo attivo può possedere è limitato e di default generalmente pari a 1024; tale è quindi il limite delle connessioni concorrentemente instaurabili.

Per quanto concerne il secondo aspetto, httperf tenta di stabilire connessioni al rate richiesto; nel caso che i file descriptor siano esauriti, il programma incrementa il contatore fd_unavail mostrato nelle statistiche finali: una misura che presenti fd_unavail diverso da zero non è attendibile, in quanto ottenuta imponendo un rate di richieste diverso da quello voluto. Per incrementare tale limite, si è effettuata una configurazione del sistema client ( [2]) prima della compilazione di httperf:

si è aggiunta la riga
<nomeUtente> hard nofile 65535
al file /etc/security/limits.conf;

si è modificata la macro #define __FD_SET_SIZE 65535 in /usr/include/bits/typesizes.h.

In questo modo sarà possibile utilizzare contemporaneamente al più 65535 descrittori. Anche con questa modifica, si manterrà limitato il parametro --rate settando opportunamente il --num-call per ottenere i rate più elevati.

Progetto degli esperimenti

Da un pre-analisi abbiamo determinato tre fattori, ed i loro livelli, che maggiormente incidono sulle prestazione e vogliamo analizzare in dettaglio gli effetti. Questi tre fattori sono:

RequestRate: rate di connessione TCP aperte, per questo fattore si sono scelti i seguenti 3 livelli: basso = 1 req/s;  medio=10 req/s; alto= 100 req/s.

NumCall: Numero di richieste http inviate su ogni connessione, per questo fatto re si sono scelti i seguenti 3 livelli: basso = 1 req/s; medio=10 req/s; alto= 100 req/s.

FileSize: Dimensione del file richiesto al server, per questo fatto re si sono scelti i seguenti 2 livelli: basso = 1 Kb;  alto= 10 Kb.

I livelli dei fattori sono stati scelti in modo da avere informazioni complete sulle prestazioni e per non far superare al server il punto di usable capacity, in quanto dopo quel punto un modello di regressione lineare non poteva essere più utilizzato per analizzare il modello, come mostreremo in appendice, se l'esperimento fosse eseguito senza questa ipotesi risultava che nessun fattore era significativo per le prestazioni; ciò era dovuto ad un errore nel modello scelto per analizzare la varianza.

Per progettare l'esperimento si è usato il metodo del Fractional Factorial Design: dal Full Factorial Design, che avrebbe previsto un numero di esperimenti pari a 3*3*2=18, sono state eliminate le configurazioni che avrebbero portato il server a un funzionamento oltre il punto di usable capacity. L'osservare tutti le combinazioni ci porta a poter determinare non solo i fattori significativi ma anche le interazioni di secondo livello tra di essi.

Misure effettuate

Effettuate tutte le osservazioni abbiamo le seguenti misure:

Analisi della Varianza e allocazione della varianza

Utilizzando il Software Jmp abbiamo effettuato l'analisi della varianza. Analizziamo inizialmente il tempo di risposta:

Nel report si possono evincere tutti i parametri necessari per effettuare le analisi.

Nel test degli effetti, si evidenziano:

Somme dei quadrati degli effetti, che sono degli indici di variabilità relativi al parametro;

Prob > F, che indica quanto è significativo il fattore, i valori con l'asterisco sono i valori significativi con una livello di confidenza superiore al 95%;

mentre nell'analisi della varianza si evidenziano:

somme dei quadrati totale (SST) e dell'errore (SSE) che danno informazioni sulla variabilità totale di tutte le osservazioni e sulla variabilità attribuita all'errore

Il rapporto tra la somma dei quadrati dei contributi dei singoli fattori e SST esprime la percentuale id variabilità spiegata da ciascuno dei fattori, questo valore ci consente di determinare, in maniera euristica, l'importanza del fattore.

In questo caso possiamo dedurre che i fattori RequestRate e NumCall insieme rappresentano circa 80% della variabilità ed un'ulteriore 15% è dovuto all'interazione dei due fattori. Questo vuol dire che i fattori RequestRate e numCall non sono indipendenti e gli effetti di uno dipendono dal livello dell'altro.

Inoltre questi due fattori e le loro iterazioni sono significativi con confidenza maggiore del 95%.

Per quello che riguarda il parametro FileSize possiamo concluedere che esprime circa il 4%della varianza e che le iterazioni con gli altri fattori sono minimi, inoltre questo parametro non è significato. Questo ci porta a poter isolare questo parametro in analisi prestazioni successive del serveWeb.

Per il ResponseTime, abbiamo il seguente report fornito da JMP

Per le stesse considerazioni fatte sopra, possiamo dire che il RequestRate e il numCall esprimono circa l'80% della variabilità ( circa 38% per il primo), e che la loro interazione spiega circa il 17%; possiamo anche dire che questi due parametri  e la loro interazione sono significativi con più del 95% di confidenza (guardando prob >F). Considerazioni analoghe per il fattore FileSize che non è importante né significativo.

Appendice

Nel caso in cui non avessimo preso i livelli per valutare i fattori come sopra, ma avessimo preso valori superiori tali da superare l'usable capacity, il modello utilizzato per valutare l'esperimento non rifletteva l'andamento reale delle metriche, in quanto i risultati delle osservazioni non avrebbero avuto un andamento lineare. Mostriamo adesso un report dove i livelli alto, medio, basso sono 1000, 100, 10 e per il fileSize 30k 1mega.

Come si evince nessun fattore è significativo e/o importante.