CAPITOLO 5
Prestazioni
5.1
Considerazioni iniziali
In questa sezione si propone un confronto fra GridFTP e SOAPw/Attachments come meccanismo di trasferimento file, valutandone in particolar modo la perfor-mance ottenuta nel testbed costruito per CONStanza. Al termine del precedente Capitolo si `e discusso su quali siano i motivi per privilegiare lo scambio di da-ti attraverso SOAPw/Attachments rispetto all’uso di GridFTP. Quest’ulda-timo ha per`o dalla sua una migliore efficienza nel trasporto dei dati: SOAP `e basato sul linguaggio general purpose XML, che risulta essere molto verboso e ridondante.
5.1.1 GridFTP
Il protocollo GridFTP `e lo standard utilizzato in Globus per lo scambio di file
su Grid. `E essenzialmente un’estensione al classico protocollo FTP, che come
protocollo di maggior utilizzo per lo scambio di file via Internet rappresentava il miglior candidato per l’utilizzo in Grid. Le principali caratteristiche di GridFTP sono[9][10]:
• supporto per le infrastrutture di sicurezza GSI e Kerberos;
• trasferimento di porzioni selezionabili di un file;
• possibilit`a di effettuare il trasferimento dati tra due calcolatori
comandan-dolo da una terza macchina remota;
• affidabilit`a: sono disponibili meccanismi per il recupero e riavvio di
trasfe-rimenti interrotti a causa di errori.
5.1.2 SOAPw/Attachment (Sw/A)
Lo standard per l’invio di dati in allegato a messaggi SOAP `e stato diffusamen-te affrontato nella Sezione 2.5. Per l’applicazione descritta nella Sezione 4 si `e voluto rispettare, per facilit`a di integrazione col sistema, il protocollo pull-based presente in precedenza che sfruttava GridFTP. Si ha quindi che il LRCS master viene contattato da uno slave, via SOAP, con una richiesta di invio. La risposta del master conterr`a l’update unit come allegato secondo lo standard MTOM. Al momento non `e stata sfruttata l’opportunit`a offerta da MTOM di trasferire l’up-date unit in streaming, il che implica che l’intero file verr`a contenuto in memoria RAM dal LRCS master prima del trasferimento e da ogni LRCS slave alla
com-pleta ricezione, prima del salvataggio su disco. `E verosimile che le prestazioni
possano beneficiare di queste caratteristiche, una volta implementate.
In questa fase di test l’utilizzo l’estensione di sicurezza GSI inclusa in CONStan-za `e stata disabilitata durante i test di Sw/A, con una conseguente maggiore velocit`a di trasferimento riscontrabile soprattutto per piccole dimensioni del file trasmesso.
5.1.3 Testbed utilizzato
Per effettuare i test sono state impiegate due macchine, una presso l’INFN di Bari e una al CNAF di Bologna. Su quest’ultima risiedevano il GRCS e un LRCS, detto LRCS1, che controllava la replica master. La macchina di Bari ospitava un LRCS slave, detto LRCS2 che richiedeva un file a LRCS1 attraverso dui client appositi, che utilizzavano uno GridFTP e l’altro Sw/A per il trasferimento dati. Il sistema operativo installato sui calcolatori utilizzati `e Scientific Linux[7]. Il collegamento di rete tra le macchine permetteva trasferimenti con una velocit`a di circa 12-15Mbps, con un RTT di circa 8 millisecondi.
5.1.4 Struttura dei test
Sono state creati dei file costituenti delle update unit fittizie per la verifica delle performance dei 2 meccanismi. Ogni update unit fittizia ha una dimensione diversa, in modo da poter valutare la scalabilit`a di entrambi i meccanismi in funzione della dimensione dei file scambiati. Le dimensioni scelte per le update unit di test coprono un range che va da un minimo di 1kB ad un massimo di 100MB. Nel caso reale di replicazione di database, la dimensione di un’update unit dipende dal numero di query comprese nel log: per avere un riferimento, si pu`o stimare che un logfile di 1kB comprenda 3-5 query, mentre un logfile di 100MB porti con s´e 350-400 migliaia di query.
5.2
Risultati dei test
Il trasferimento di ogni update unit di test `e stato ripetuto per dieci volte per entrambi i meccanismi di trasferimento. I risultati di ogni decupla sono stati
0 5000 10000 15000 20000 25000 30000 35000 40000 100MB 50MB 20MB 10MB Tempo (millisecondi)
Dimensione del file (log)
GridFTP vs SOAPw/Attachment : grandi dimensioni
gridftp swa
Figure 5.1: Risultati dei test
risultato dei test per file di “grandi” dimensioni, a partire da 10MB fino a 100MB.
5.3
Risultati dei test
Il trasferimento di ogni update unit di test `e stato ripetuto per dieci volte per
entrambi i meccanismi di trasferimento. `E possibile notare invece in Figura 5.2
come per valori piccoli dell’update unit, da 1kB fino a 10MB, il tempo impiega-to dal meccanismo di trasmissione Sw/A sia comparabile e spesso molimpiega-to minore di quello utilizzato per lo stesso update con GridFTP. Verosimilmente per`o il netto vantaggio di Sw/A per le piccole dimensioni `e da attribuibile all’assenza dell’estensione di sicurezza, che permette di scavalcare i check di verifica delle
0 1000 2000 3000 4000 5000 10MB 5MB 1MB 100kB Tempo (millisecondi)
Dimensione del file (lineare)
GridFTP vs SOAPw/Attachment : piccole dimensioni
gridftp swa
Figure 5.2: Risultati dei test
credenziali. Si pu`o infatti notare che i tempi necessari a GridFTP per trasferire un file sono praticamente identici per update file di 1kB, 100kB e 1MB. Questo si pu`o spiegare imputando all’handshake GSI un grosso impatto iniziale in termini di tempo, e riducendo ad un tempo relativamente trascurabile l’effettivo trasferi-mento del file, che data la capacit`a di linea dovrebbe risolversi in poche frazioni di secondo.
All’aumentare della dimensione dell’update unit si pu`o notare come il rapporto tra i due metodi cambi radicalmente, con una performance di Sw/A nettamen-te degradata al crescere del numero di dati da trasferire. Per l’updanettamen-te unit da 100MB si arriva quasi al doppio del tempo necessario con GridFTP, mentre per dimensioni tra i 10MB e i 20MB le prestazioni sono comparabili. In questo caso
`e possibile imputare la lentezza di Sw/A per grandi dimensioni di file da trasfe-rire all’assenza di un meccanismo di straming che eviti la copia totale del file in memoria prima del trasferimento e da memoria a unit`a disco a lato ricevitore.
