Dagli esempi di codice contenuti nei post precedenti, si evince che l'oggetto principalmente utilizzato lato applicazione client, per sfruttare la cache di Velocity, è un oggetto di tipo DataCache.
Un'applicazione Velocity-enabled, utilizza il DataCache per contattare il cluster ed eseguire ad esempio le operazioni di ADD, PUT e GET. Velocity dispone di due tipi di cache client (DataCache): Simple Client e Routing Client. E' possibile decidere quale tipo di client utilizzare sia tramite il file di configurazione, che in maniera programmatica utilizzando i parametri del costruttore della DataCacheFactory, come di seguito illustrato:
Un simple client è indicato solo nei casi in cui uno o più cache host non siano raggiungibili, ad esempio a causa della topologia della rete o per altri motivi. Durante un operazione di GET, il client contatterà uno dei cache host raggiungibili, poniamo Server1, e nel caso in cui l'oggetto richiesto sia stato collocato fisicamente su di un altro cache host, poniamo Server2, il cahce host Server1 provvederà a reperire l'oggetto da Server2 e restituirlo al client.
Il routing client, da preferire ove possibile, mantiene una routing table nella memoria locale del client, in modo da contattare direttamente il cache host che contiene l'oggetto/item richiesto.
E' evidente che il routing client è vincente, in termini di prestazioni, rispetto al simple client: il primo infatti contatta direttamente il cache host che contiene fisicamente l'oggetto ricercato, mentre il secondo contatta il primo cache host disponibile che potenzialmente a sua volta contatterà un altro cache host che contiene l'oggetto ricercato.
Entrambi i client, possono beneficiare di una feature comune: la local cache. Ricordiamo, come illustrato nel primo post di questa serie, che quando un oggetto viene richiesto al cluster con un GET, questo sarà serializzato, trasportato verso il client ed infine deserializzato. La local cache consente di mantenere nella memoria locale del client una copia deserializzata degli oggetti "transitati" in seguito ad operazioni di ADD,GET e PUT.
L'aggiornamento della local cache si basa su 2 differenti approcci, selezionabili in fase di creazione della dataCache: Timeout-Based e Notification-Based. Il primo è un semplice intervallo di tempo, scaduto il quale, viene richiesta al cluster una nuova versione della routing table, il secondo, invece, sfrutta le notifiche il cui funzionamento è stato illustrato in un precedente post, ma è disponibile solo nel caso si utilizzi un routing client.
L'utilizzo della local cache, implica che l'applicazione client possa ottenere una versione "obsoleta" dell'oggetto in cache, in quanto l'aggiornamento della local cache non è istantaneo in seguito alla modifica di un oggetto da parte di un altro client. Se i requisiti tollerano situazioni di questo tipo, la local cache può contribuire significativamente all'aumento delle prestazioni dell'applicazione, come di seguito dimostrato:
Nel test è stato utilizzato prima un simple client, quindi un routing client ed infine un routing client con local cache attivata. Il miglioramento dei tempi risulta evidente già quando si utilizza un routing client, con la local cache attivata è scontato.
posted @ sabato 18 luglio 2009 19:03