Questo documento si propone di integrare quelli precedentemente proposti , notificando I cambiamenti che sono stati apportati n sede di verifica e collaudo del software e integrando il tutto con una completa analisi prestazionale sull'intera implementazione.

In fase di collaudo del software si è riscontrato che questo presentava una notevole inefficienza in particolar modo risultavano piuttosto lunghi I tempi di attesa dal lato del client che a fronte di ogni richiesta doveva interrogare tutta la gerarchia di server per ritrovare la filiale interessata. Tale attesa risutava del tutto inutile ad esempio per le richieste ripetute fatte verso la medesima filiale di cui si conosceva già l'indirizzo.

Tale scelta di mantenere il client Stateless nei confronti della connessione risultava anche parecchio onerosa per I server che dovevano far fronte a un traffico di rete sempre piuttosto elevato.

Per far fronte a questo problema si è ipotizzata l'introduzione di una memoria cache che mantenga traccia degli indirizzi delle filiali consultate in modo che per un'ulteriore richiesta il client vi possa accedere direttamente, secondo il seguente schema :

Un problema che si pone a fronte dell'introduzione di questa memoria di accesso locale è quello della sua gestione ed in particolare del suo eventuale aggiornamento.

Le informazioni che essa contiene possono non essere aggiornate ,quindi possono risultare inconsistenti. La soluzione che abbiamo scelto in questa implementazione è quella che sicuramente introduce un minore overhead comunicativo , si è pensato infatti che la fase di aggiornamento della cache avvenga soltanto a fronte di un mancato collegamento , ossia di una possibile inconsistenza.

In questo caso il collegamento è assai più lento perchè il client deve per prima cosa consultare il nodo filiale indicato dalla cache , una volta constatata l'impossibilità deve ripercorrere la gerarchia DNS per ottenere il nuovo indirizzo fisico e quindi aggiornare la memoria cache .In questo caso le prestazioni si deteriorano parecchio , ma si considera questo come un'evento eccezzionale , quindi il suo verificarsi è plausibilmente considerabile raro , tanto da non compromettere le prestazioni globali.

In questa sede si è scelto mantenere traccia sempre di tutti gli indirizzi delle filiali consultate , il DB potrebbe crescere notevolmente , quindi si potrebbero anche ipotizzare delle politiche di sostituzione che dopo un certo periodo di giacenza senza consultazione sostituiscano I dati vecchi e meno consultati.

ANALISI DELLE PRESTAZIONI.

A conclusione della relazione proponiamo alcune prove di collaudo del software in particolare cercandone di evidenziare le diverse prestazioni nelle situazioni più comuni di lavoro.

Le seguenti prove sono state effettuate senza caricare eccessivamente I server di dati e senza simulare ,come in effetti accade realmente una situazione di elevato numero di client connessi per richieste. A fronte di questa considerazione diciamo che occorre non considerare tali prestazioni come valori rilevanti in senso assoluto ma relativamente agli altri valori stessi come indicazione del migliore utilizzo del software stesso.

BENCH-MARK .

L'intero pacchetto software è stato provato in due diverse situazioni , la prima in un ambito locale simulando il lavoro di rete , su un personal PC 200 mhz ,la seconda simulando invece la situazione reale di un ambiente distribuito utilizzando le workstation del LAB2.

I dati conseguiti nel test in locale non devono essere considerati significativi di per se ma soltanto come confronto delle diverse situazioni di lavoro e soprattutto tale prova realizzando in locale tutti I processi server simula le condizioni di lavoro con forte richiesta .

-Ricerca di un conto corrente partendo dalla gerarchia DNS : il processo client deve ripercorrere tutta la gerarchia discendendo fino alla filiale per poi collegarsi a questa rappresenta un lavoro di routine nel caso di chiamate effettuate da utenti diversi , quindi senza la possibilità di utilizzare la cache.

RISULTATO : T=12 sec. (non è importante cnsiderare I secondi di per se ma l'ordine di grandezza).

-Ricerca di un conto corrente già presente in cache memory:tale situazione mette in evidenza I vantaggi ottenuti introducendo una cache di sistema (tra l'altro in questa versione implementata in modo piuttosto inefficiente attraverso il file system) . L'ordine di grandezza delle mie prestazioni è notevolmente modificato , si arriva a ridurre ad un terzo I tempi di attesa.

RISULTATO:= T 4 secondi.

-Inserimento utilizzando dati di cache non più validi: è questo sicuramente il caso peggiore , dove si paga il prezzo di aver deciso di non modificare la cache se non di fronte ad una manifesta situazione di errore. In questo caso il Client deve contattare il nodo indicato dalla cache e solo dopo non averlo trovato ripercorrere tutti I nodi DNS per ritrovare il giusto percorso.

RISULTATO:=T 14 secondi.

L'incremento di tempo di attesa vediamo che è piuttosto modesto anche in considerazione del fatto che queste situazioni sono ipotizzate piuttosto rare. Questo giustifica la nostra scelta implementativa e ce ne conferma la validità.