Analisi delle prestazioni

Si sono svolti alcuni test dell’applicazione con diverse configurazioni per valutarne le prestazioni e la scalabilità.

I risultati che vengono successivamente riportati si riferiscono a prove effettuate sulle macchine del lab3, su jdk1.2.2 per Windows NT.

L’obiettivo era valutare le prestazioni di comunicazione del sistema e per questo si è cercato di distribuire nel modo più uniforme possibile i componenti sulle macchine. In particolare, visto anche i limiti di memoria delle postazioni e la relativa pesantezza della JVM, si sono posti i server utilizzati per una stessa prova su nodi diversi, mentre per l’ultima prova, che vedeva variare il numero di clienti, se ne sono posti al massimo due su uno stesso nodo.

Sempre nell’ottica di valutare gli effettivi tempi di comunicazione, si trattava di neutralizzare il comportamento della JVM riguardo al caricamento delle classi. Il suo comportamento a default infatti prevede l’uso del JIT (Just In Time) Compiler, cioè quando una classe viene caricata per la prima volta il JIT trasforma il codice interpretato in codice macchina, che sarà poi utilizzato successivamente. A livello di prestazioni questo si traduce in un ritardo per ogni caricamento di una nuova classe ed in una successiva ottimizzazione quando la classe viene utilizzata in seguito.

Per questo le prove che abbiamo effettuato sono state eseguite più volte mediando i risultati e tralasciando la prima esecuzione.

Per valutare le prestazioni si sono misurati i tempi necessari ad un client o ad un server per eseguire una operazione. Si è fatto in modo di stampare su console un messaggio in corrispondenza dell’inizio dell’operazione e della fine della medesima, vista dallo stesso componente. Si è fatto uso della classe java.text.SimpleDateFormat per stampare l’ora corrente.

Come prima cosa si è voluto valutare il tempo impiegato da un server per entrare in una rete all’aumentare del numero di server presenti nella rete stessa.

Il grafico dei tempi ottenuto è il seguente :

Come era da aspettarsi vista l’organizzazione del sistema, tale operazione risulta non scalabile e presenta un andamento pressoché lineare all’aumentare del numero dei server. Infatti ogni nuovo server entrante mette in moto il protocollo 2PC per garantire su tutti i server la consistenza dell’ingresso ed inoltre deve contattare ogni server già presente nel sistema per reperire le stanze dei giochi presenti su ognuno di essi. Evidentemente queste operazioni hanno durata dipendente dal numero di server connessi.

Si sono poi fatte prove per rilevare le durate delle operazioni compiute dai clienti, anch’esse al variare del numero di server connessi.

Si sono misurati i tempi di connessione al sistema, di creazione di una partita e di invio di un messaggio pubblico.

Il criterio con cui sono state scelte tali operazioni è stato quello di sollecitare i server a compiere azioni strutturalmente diverse. Infatti :

• La connessione di un nuovo utente comporta l’applicazione del protocollo 2PC a livello MainServer
• La creazione di una partita comporta l’applicazione del protocollo 2PC a livello RoomServer
• L’invio di un messaggio pubblico non presenta problemi di consistenza e viene eseguita senza nessun coordinamento preventivo

I grafici che illustrano i risultati delle prove compiute sono i seguenti :

Come si può notare, le prime due operazioni presentano una durata sostanzialmente lineare con il numero di server connessi.

L’invio di un messaggio invece ha una durata quasi costante, anche grazie alla struttura ad eventi realizzata nel sistema. Non si ha comunque un andamento perfettamente costante, come ci si potrebbe aspettare idealmente, perché la presenza di più server comporta anche la presenza di più thread (cfr. progetto) che quindi competono per acquisire la CPU su uno stesso nodo.

L’ultima prova realizzata, a differenza delle precedenti, ha valutato la durata di un’operazione compiuta da un client al variare non del numero di server, ma di quello di clienti presenti.

Ciò che si voleva verificare era la ricercata scalabilità di questo aspetto, cioè di come il numero di clienti connessi influenzi poco i tempi di esecuzione delle operazioni.

Per fare questo si sono connessi due server ed i clienti che entravano si connettevano alternativamente all’uno e all’altro server. L’operazione che si è effettuata, a titolo di esempio, è stata la creazione di una partita.

I tempi misurati sono rappresentati nel seguente grafico :

Si può quindi dire che l’obiettivo, almeno in parte, è stato raggiunto. Riguardo il lieve incremento comunque presente valgono i ragionamenti fatti precedentemente al riguardo.

Test di correttezza

Si sono realizzate anche delle prove per valutare la correttezza dell’implementazione del protocollo 2PC. Si sono di fatto riprodotte tutte le situazioni di interferenza, così come presentate nel progetto con più server e più client connessi e si è riscontrato sempre un corretto funzionamento.