In questo capitolo verranno mostrate le analisi di performance effettuate sul pro-totipo di IRL illustrato nel capitolo 5. In particolare, prima verr`a definito l’am-biente in cui `e sono stati effettuati i test, e poi verr`a descritto l’insieme degli esperimenti effettuati. Verranno poi mostrati i risultati ottenuti in termini di latenza e throughput, mostrando cos`ı la fattibilit`a e la scalabilit`a dell’approccio a tre livelli.
6.1 Ambiente e test preliminari
L’ambiente usato per effettuare i test consiste di sei workstation Intel Pentium II 600, con sistema operativo Microsoft Windows NT Workstation 4.1 sp6, e Java Development Kit v.1.3.1. Su ogni macchina sono stati installati e configurati due ORB Java:
• JacORB v1.3.21 ([35]);
• IONA’s ORBacus v.4.1 ([33]).
Le workstation sono interconnesse tra loro tramite una LAN Ethernet a 10Mbit, configurata come un singolo dominio di collisione.
Come gi`a detto nella sezione 4.4, la correttezza del protocollo si basa sull’uti-lizzo di una failure detection perfetta ([11]). Il primo test effettuato riguarda la
valutazione del carico di lavoro (sia carico di rete che carico dei processori) al quale si pu`o assumere valida tale ipotesi.
Per come `e strutturata l’architettura, solo il rilevamento del guasto di un host `e soggetto ad errori1; per rilevare gli errori sul rilevamento di guasto dell’intero host si `e fissato il periodo di heartbeat del LocalFailureDetector e abbiamo variato il carico di rete dallo 0% fino al 100% usando un generatore di traffico basato su un UDP multicast. L’heartbeat per il rilevamento del guasto dell’host `e stato effettuato sia attraverso UDP che TCP. Inoltre, per valutare la sensibilit`a del rilevamento del guasto dell’host al carico di lavoro della macchina, `e stato fatto variare anche il carico di lavoro dell’host su cui risiede l’IRLFaultNotifier.
I risultati ottenuti sono mostrati nella Figura 6.1, che mostra il minimo incre-mento percentuale (%∆T) da applicare al timeout usato dall’IRLFaultNotifier per rendere affidabile il rilevamento del guasto di un host, in funzione del carico della rete. Dato un certo carico di rete, per evitare che l’IRLFaultNotifier commetta errori rilevando il guasto di un host, si deve settare il timeout ad un valore mag-giore o uguale a quello indicato nella figura; ad esempio, con un massimo carico di rete di 4Mbps, settando il periodo di heartbeat dei LocalFailureDetector ad 1sec., il valore del timeout da settare per rilevare guasti dell’host in modo affidabile `e di 1,05 sec. (usando UDP o TCP con basso carico di lavoro sulla macchina)o 1,2 sec. (usando TCP ed alto carico di lavoro della macchina). Tutti gli esperimenti effettuati sono stati fatti controllando il carico di lavoro dell’host su cui risiedeva il fault notifier e controllando il traffico di rete, con lo scopo di evitare falsi sospetti.
I test sono stati effettuati definendo opportuni parametri di interesse, descrit-ti in Figura 6.2, e riguardano essenzialmente la latenza media di un client, e il throughput globale del sistema usando un “hello server” sigle thread, cio`e che processa ogni richiesta una alla volta, e che accetta richieste di dimensione vari-abile (parametroS e risponde immediatamente. La misura `e stata fatta facendo
1Visto che il solo guasto previsto `e quello di tipo crash, il LocalFailureDetector genera un fault report solo se l’oggetto monitorato non risponde all’invocazione del metodo is alive().
6.1. AMBIENTE E TEST PRELIMINARI 63 QHWZRUNORDG 0ESV %∆Τ 7&3 7&3 +/ 8'3 VDIH]RQH
Figura 6.1: Accuratezza nel rilevamento dei guasti degli host.
Parameter Description Values
FR valore booleano: vale TRUE se e solo se il test implica un guasto del mid-tier T/F
FM valore booleano: vale TRUE se e solo se il test implica in guasto di un
membero degli object group T/F
C valore intero: numero di client conorrenti 1,2,4,8
M valore intero: numero di membri dell'object group 2,3,4
S valore intero: dimensione della richiesta 1,5,10,20K
Latenza media del client (msec)
Clients (C) 1 2 4 8 16
JacORB 1,28 1,37 2,30 4,34 8,30 ORBacus 1,30 1,38 2,23 3,47 7,08
Throughput globale del sistema (richieste/sec)
Clients (C) 1 2 4 8 16
JacORB 769 1458 1741 1841 1926 ORBacus 729 1448 1808 2308 2262
Tabella 6.1: Performance dell’interazione client/server base
invocare al client un batch di 50000 richieste, per poi effettuare la media delle misure ottenute. Per confrontare la latenza e il throughput di IRL con le perfor-mance di una invocazione standard CORBA, `e stata misurata la latenza media e il throughput del sistema di una semplice interazione tra un client ed un server non replicato. I risultati sono mostrati in Tabella 6.1. Nel seguito indicheremo con L∗ il rapporto tra la latenza misurata negli esperimenti effettuati e la latenza della semplice interazione client server mostrata in Tabella 6.1.
6.2 Performance per oggetti replicati stateless
Con questo schema di replicazione, i membri degli object group sono invocati direttamente dai client, che usano l’ORGW di IRL per la reinvocazione e la redi-rezione delle invocazioni a fronte di guasti. La Figura 6.3 mostra il valore di L∗ ottenuto settando C=1, M=2, S=1K in entrambi i casi di esecuzione senza guasti (FM=FALSE) ed esecuzione con guasto (FM=TRUE). Si pu`o notare che l’ORGW introduce un piccolo ritardo nell’esecuzione senza guasti (circa 13% con JacORB, 31% con ORBacus), mentre triplica la latenza subito dopo la reinvocazione dovu-ta al guasto del membro dell’object group che sdovu-tava servendo la richiesdovu-ta. La Figura 6.4 mostra invece il throughput: la diminuzione delle richieste servite al secondo `e dovuto alla presenza di ORGW.
6.2. PERFORMANCE PER OGGETTI REPLICATI STATELESS 65 1,13 3,30 1,31 2,97 0 1 2 3 4
without reinvocation (FM=F) with one reinvocation (FM=T)
L*
jacorb orbacus
C=1, M=2, S=1K
Figura 6.3: Latenza del client.
300 400 500 600 700 800
basic benchmark stateless replication
req u est s /s e c
jacorb (without reinvocation) orbacus (without reinvocation)
FM=F, C=1, M=2, S=1K
6.3 Performance per oggetti replicati stateful
Nei seguenti test verranno misurate le prestazioni del protocollo di replicazione a tre livelli descritto nella sezione 4.4: i client, che usano l’ORGW per gestire la reinvocazione, invocano una richiesta di una fissata dimensione S sulla replica
primary dell’ObjectGroupHandler, che poi inoltra tale richiesta all’object group che controlla, formato da M membri. Ogni membro dell’object group `e dota-to del componente IRGW co-located ([31]). Negli esperimenti si far`a variare il valore di C, M e S; inoltre si considerer`a solo il guasto dell’ObjectGroupHandler primary (FM=FALSE, FR=TRUE/FALSE), visto che il guasto di un membro dell’object group causa solo un aumento di latenza, cos`ı come gi`a visto nel caso di Figura 6.3. Non si considerer`a neanche il guasto di un host, visto che com-porta semplicemente un ritardo proporzionale al timeout usato dal fault notifier per rilevare il guasto. (Figura 6.1). Inoltre si considerer`a trascurabile il ritardo introdotto dai LocalFailureDetector e dall’IRLFaultNotifier dovuto alla rilevazione dei guasti degli oggetti.