Shared Cache: best practice per l'invalidazione

11

Mi piacerebbe sapere quale sarebbe un approccio migliore per invalidare / aggiornare gli oggetti cache.

Prerequisiti

  • Avere un server memcached remoto (che funge da cache per più applicazioni)
  • Tutti i server sono ospitati da Azure (regioni di affinità, stessi data center)
  • La dimensione dell'oggetto della cache varia da 200 byte a 50 kilobyte


Approccio 1 (memorizza nella cache al più presto)

  1. L'oggetto A è stato creato - > memorizza nel database e memorizza nella cache
  2. Oggetto A richiesto dal client - > controlla la cache per l'esistenza, altrimenti recupera dal database e memorizza nella cache
  3. L'oggetto A viene aggiornato - > archivia nel database, memorizza nella cache

L'approccio 1 sembra essere più semplice. Se qualcosa viene creato, inserisci la cache al più presto. Indipendentemente da qualcuno ne avrà bisogno.


Approccio 2 (archivio cache pigro)

  1. L'oggetto A è stato creato - > archivia nel database
  2. Oggetto A richiesto dal client - > controlla la cache per l'esistenza, altrimenti recupera dal database e memorizza nella cache
  3. L'oggetto A viene aggiornato - > memorizza nel database, elimina la chiave nella cache

L'approccio 2 sembra essere più consapevole della memoria. In questo approccio solo gli elementi richiesti vanno nella cache.


Domanda 1: Considerando le prestazioni, quale sarebbe un approccio migliore? La memoria e la CPU non contano ancora.

Domanda 2: I miei pensieri sono una specie di ottimizzazione prematura?

Domanda 3: altri pensieri? Altri approcci?

    
posta lurkerbelow 12.01.2013 - 12:04
fonte

2 risposte

11
  1. È senza risposta, tranne che per dire dipende. Ci sono molti fattori che determineranno quale approccio sarà il migliore nel tuo caso, ad esempio: è normale che gli oggetti creati siano recuperato poco dopo che sono stati creati? Qual è il rapporto tra gli aggiornamenti agli accessi?
  2. Re. decidendo che hai bisogno di una cache: se stai ottimizzando senza dati allora sì, è tecnicamente prematura l'ottimizzazione. Dico tecnicamente in quanto esperienza / saggezza convenzionale potrebbe dirti che avrai bisogno di una cache di qualche tipo. Ri. decidere come funziona meglio la cache: sì, è sicuramente l'ottimizzazione prematura.
    • L'ottimizzazione spesso non riguarda la ricerca della soluzione migliore / più ottimale. Dovrebbe andare come segue:
      1. Trova i colli di bottiglia nel sistema.
      2. Trova dove puoi fare la differenza più grande con la minor quantità di lavoro.
      3. Fai meno lavoro!
      4. È abbastanza veloce ancora? In caso contrario, vai al # 1.
      5. Fatto!
    • Onestamente, nessuno degli approcci che descrivi sembra complicato. Perché non implementare entrambi e vedere quale funziona meglio?
    • Il passaggio 3 nell'approccio # 2 potrebbe essere modificato in "L'oggetto A viene aggiornato - > memorizza nel database, aggiorna la voce nella cache".
risposta data 14.01.2013 - 12:48
fonte
2

memcached gestisce gli oggetti con i propri criteri, che scadranno se l'oggetto memorizzato nella cache non viene accesso a nessuno o se la memcached esaurisce la memoria. Pertanto, il tuo primo approccio non è una buona idea in quanto il tuo oggetto in memcached continuerà a essere invalidato a causa di esaurimento della memoria durante la creazione di oggetti.

Q1. L'approccio 2 sarebbe migliore in termini di prestazioni perché non invia oggetti a memcached, sebbene il miglioramento delle prestazioni sia molto limitato.

Q2. È difficile da dire. Supponiamo che tu conosca il collo di bottiglia e progetti gli approcci che non sarebbero prematuri.

Q3. Ci sono altri approcci come la cache solo in memcached.

    
risposta data 14.01.2013 - 14:03
fonte

Leggi altre domande sui tag