Caching di AppFabric - Uso corretto di DataCacheFactory e DataCache

Question

Sto cercando il modo più performante per organizzare l'utilizzo del datacache e della datacache factory per le chiamate di caching AppFabric, per il caricamento della cache da 400 a 700 per pagina (e quasi tutte le put) . Sembra che usare una singola DataCacheFactory statica (o forse una coppia in una configurazione round-robin) sia la strada da percorrere.

Chiamare GetCache ("cacheName") per ogni richiesta di oggetto DataCache o faccio uno statico nel momento in cui DataCache factory è inizializzato e lo uso per tutte le chiamate?

Devo gestire le eccezioni, controllare i codici di errore e riprovare?

Devo considerare la contesa quando più thread tenta di utilizzare l'archivio cache e desidera lo stesso elemento (per chiave)?

Esiste qualche tipo di documentazione che esplori correttamente il design e l'utilizzo di questo?

---

Alcune informazioni che ho raccolto finora dal forum:

http://social.msdn.microsoft.com/Forums/en-AU/velocity/thread/98d4f00d-3a1b-4d7c-88ba-384d3d5da915

"Creazione di fabbrica comporta la connessione al cluster e può richiedere un certo tempo, ma una volta che si. avere l'oggetto factory e la cache con cui vuoi lavorare, puoi semplicemente riutilizzare quegli oggetti per fare puts e ottenere nella cache, e dovresti vedere prestazioni molto più veloci. "

http://social.msdn.microsoft.com/Forums/en-US/velocity/thread/0c1d7ce2-4c1b-4c63-b525-5d8f98bb8a49

"Creazione di un'unica DataCacheFactory (Singleton) è più performante rispetto alla creazione di DataCacheFactory multipla. Non è necessario creare DataCacheFactory per ogni chiamata, avrà calo di prestazioni."

"Si prega di provare ad incapsulare l'algoritmo round-robin (con 3/4/5 istanze di fabbrica) nel singleton e confrontare i risultati del test di carico."

http://blogs.msdn.com/b/velocity/archive/2009/04/15/pushing-client-performance.aspx

"è possibile aumentare il numero di clienti per aumentare il throughput cache. Ma a volte, se si vuole avere più piccolo insieme di clienti e aumentare la produttività, un trucco è quello di utilizzare più istanze DataCacheFactory. L'istanza DataCacheFactory crea una connessione ai server (e..g se ci sono 3 server, creerà 3 connessioni) e multiplex tutte le richieste dai datacaches a queste connessioni.Quindi se il volume put/get è molto alto, queste connessioni TCP potrebbero essere un collo di bottiglia, quindi un modo è creare più istanze DataCacheFactory e quindi utilizzare le operazioni su di esse. "

---

Ecco ciò che è in uso finora ... la proprietà si chiama e se si esegue il valore restituito non è null un'operazione.

private static DataCache Cache 
{ 
    get 
    { 
     if (_cacheFactory == null) 
     { 
      lock (Sync) 
      { 
       if (_cacheFactory == null) 
       { 
        try 
        { 
         _cacheFactory = new DataCacheFactory(); 
        } 
        catch (DataCacheException ex) 
        { 
         if (_logger != null) 
         { 
          _logger.LogError(ex.Message, ex); 
         } 
        } 
       } 
      } 
     } 

     DataCache cache = null; 

     if (_cacheFactory != null) 
     { 
      cache = _cacheFactory.GetCache(_cacheName); 
     } 

     return cache; 
    } 
} 

---

Vedere questa domanda su Microsoft AppFabric forum: http://social.msdn.microsoft.com/Forums/en-AU/velocity/thread/e0a0c6fb-df4e-499f-a023-ba16afb6614f

Answer 1

Ecco la risposta del post sul forum:

Hi. Ci scusiamo per la risposta ritardata, ma voglio dire che queste sono ottime domande e probabilmente saranno utili per gli altri .

Non ci dovrebbe essere bisogno di più di una DataCacheFactory per thread meno che non si richiedono diversi configurazioni. Ad esempio, se si programmazione configurare il DataCacheFactory con la classe DataCacheFactoryConfiguration, allora si potrebbe desiderare di creare uno che ha cache locale abilitato e un altro che non lo fa. In questo caso, l'utente utilizza diversi oggetti DataCacheFactory a seconda della configurazione richiesta per lo scenario. . Ma altre rispetto alle differenze nella configurazione, è possibile che non visualizzi un aumento delle prestazioni da creando più DataCacheFactories.

Sullo stesso soggetto, c'è un impostazione MaxConnectionsToServer (sia programmatico DataCacheFactoryConfiguration o file di configurazione dell'applicazione come attributo dell'elemento dataCacheClient ).Determina il numero di chennels per DataCacheFactory che sono aperti al cluster di cache. Se si hanno requisiti di throughput elevati e anche larghezza di banda CPU/rete disponibile, l'aumento di questa impostazione su 3 o superiore può aumentare il throughput. Si consiglia di non aumentare questo senza causa o per un valore che è troppo alto per le proprie esigenze. È necessario modificare il valore e quindi verificare lo scenario per osservare i risultati. Noi speriamo di avere più indicazioni ufficiali su questo in futuro.

volta che hai un DataCacheFactory, si non c'è bisogno di chiamare GetCache() più volte per ottenere più datacache oggetti. Ogni chiamata a GetCache() per la stessa cache sullo stesso factory restituisce lo stesso oggetto DataCache DataCache. Inoltre, una volta ottenuto l'oggetto DataCache , non è necessario continuare a chiamare DataCacheFactory per esso. È sufficiente memorizzare l'oggetto DataCache e continuare a utilizzarlo. Tuttavia, non lasciare che l'oggetto DataCacheFactory venga eliminato. La durata dell'oggetto DataCache è legata all'oggetto DataCacheFactory.

Non dovresti mai preoccuparti della contesa con Richiedi richieste. Tuttavia, con richieste Put/Add, può esserci contesa se più cache di dati I client aggiornano la stessa chiave allo allo stesso tempo. In questo caso, l'utente riceverà un'eccezione con un codice di errore ERRCA0017, RetryLater e uno sottostato di ES0005, KeyLatched. Tuttavia, è possibile aggiungere con facilità alla gestione eccezioni e riprovare la logica per tentare l'aggiornamento quando si verificano errori come questi. Questo può essere fatto per i codici RetryLater con vari valori di sottostato. Per ulteriori informazioni su , vedere http://msdn.microsoft.com/en-us/library/ff637738.aspx. È inoltre possibile utilizzare il blocco pessimistico utilizzando le API GetAndLock() e PutAndUnlock(). Se si utilizza questo metodo , è responsabilità dell'utente assicurarsi che tutti i client di cache utilizzino il blocco pessimistico . Una chiamata Put() cancella un oggetto precedentemente bloccato da GetAndLock().

Spero che questo aiuti. Come ho detto, abbiamo speriamo di ottenere questo tipo di guida in alcuni contenuti formali presto. Ma è meglio condividerla qui sul forum fino ad allora. Grazie!

Jason Roth

Answer 2

chiamo GetCache ("cacheName") per ogni richiesta oggetto DataCache, o fare Faccio una statica al time DataCache factory è inizializzato e lo usa per tutte le chiamate?

Suppongo che la risposta dovrebbe essere; provare in entrambi i modi e vedere se c'è una differenza, ma una DataCache statica mi sembra più sensata di una chiamata corrispondente a GetCache per ogni chiamata a Get.

E 'Pushing client Performance' articolo suggerisce che c'è un luogo privilegiato in cui il numero di istanze DataCacheFactory si ottiene il massimo delle prestazioni oltre il quale il sovraccarico della memoria inizia a lavorare contro di voi - è un peccato che non hanno dato delle linee guida (o anche una regola empirica) su dove potrebbe essere questo posto.

Non ho trovato alcuna documentazione sull'ottimizzazione delle prestazioni: penso che AppFabric sia ancora troppo nuovo per queste linee guida che sono state ancora scosse. Ho dato un'occhiata ai Contenuti per lo Pro AppFabric book, ma sembra molto più preoccupato in generale con il lato del flusso di lavoro (Dublino) di AppFabric piuttosto che con il pezzo di caching (Velocity).

Una cosa però direi: esiste la possibilità di memorizzare nella cache oggetti "chunkier" in modo da poter effettuare meno chiamate allo Get? Potresti memorizzare nella cache le raccolte piuttosto che i singoli oggetti e quindi decomprimere le raccolte sul client? Mi sembra che un carico di 700 cache per pagina sia un numero enorme!