Che cosa rappresenta esattamente il limite delle dimensioni di Memcached con lo storestore del file system?

Question

Buon pomeriggio,

Ho memorizzato Memcached nella mia app su Heroku. Il limite per il piano gestito gratuitamente è 5 MB per Memcached e 25 MB per Memcachier. Essendo nuovo a praticamente tutto, speravo solo nel chiarimento di cosa esattamente rappresentasse.

Ho installato il DalliStore nel mio file di configurazione e le opzioni tipiche configurate per Rack :: Cache. Il mio metastore è in Memcache e l'archivio di entitay è impostato sul filesystem.

Domande:

1. Questo significa che il mio limite del 5/25 MB è utilizzato solo dalla meta-informazioni che sto Memorizzazione su ogni frammento di cache? Ciò significherebbe che sarei in grado di memorizzare una tonnellata di informazioni solo sui piani gratuiti?

2. Che cosa è esattamente il guasto/storia tra Rack :: Cache e Memcache (tramite negozio Dalli?) Servono a scopi diversi? Stanno facendo la stessa cosa? cioè è il seguente codice ridondante

   config.cache_store = :dalli_store

e

config.action_dispatch.rack_cache = { 
    :verbose  => true, 
    :metastore => Dalli::Client.new, 
    :entitystore => 'file:tmp/cache/rack/body', 
    :allow_reload => false 
} 

Answer 1

Ho litigato con problemi simili.

Prima di tutto, prendiamo la nostra terminologia corretta.

• Memcached: un processo in esecuzione su un server da qualche parte (d è per il demone) che memorizza in realtà coppie chiave-valore in memoria.
• cache_store: Archiviazione cache Rails (Rails.cache) con una singola API che può essere configurata per utilizzare diverse implementazioni software Ruby. Un'impostazione per config.cache_store è :memory_store per utilizzare un'implementazione in memoria. Un'altra impostazione è :dalli_store che specifica utilizzando la gemma Dalli, che sotto il cofano effettua una connessione remota, eventualmente, al server memcached.
• Dalli Store: Presumo intendi la cache di Rails supportata dalla gemma dalli, che memorizza fisicamente i valori in memcached.
• Rack :: Cache: middleware rack che inserisce intestazioni (scadenza, Cache-Control, ETag, ecc.) Nelle risposte HTTP e funge anche da cache del proxy inverso, gestendo le richieste prima che colpiscano lo stack Rails quando possibile. Vedi website.

Per consentire a Rack :: Cache di gestire le richieste prima che colpiscano lo stack Rails e il resto dell'app, è necessario memorizzare le risposte + i metadati da qualche parte. Dove memorizza le cose sono configurate dall'impostazione config.action_dispatch.rack_cache = { ... }.

Avviso, questo è un diverso impostazione da config.cache_store = :dalli_store. Non devono essere correlati. Penso che da qui provenga molta confusione. In pratica, però, potremmo volere che entrambi usassero memcached, il che significa usare l'implementazione dalli. Tuttavia, ognuno di essi ha la propria istanza Dalli::Client. (Inoltre, il tuo session_store potrebbe essere correlato, ma non deve essere.)

Lo stack di cedro Heroku ha uno ephemeral file system che non può essere condiviso tra i dynos. Tuttavia, Heroku stessi recommend using tmp file storage with Rack::Cache solo per il entitystore, con memcached utilizzato per la metastore.

Quanto a ciò che effettivamente viene memorizzato nel metastore Rack :: Cache, questi sono i documenti da rack-cache v1.2 Rack::Cache::MetaStore classe:

The MetaStore is responsible for storing meta information about a 
request/response pair keyed by the request's URL. 

The meta store keeps a list of request/response pairs for each canonical 
request URL. A request/response pair is a two element Array of the form: 
    [request, response] 

The +request+ element is a Hash of Rack environment keys. Only protocol 
keys (i.e., those that start with "HTTP_") are stored. The +response+ 
element is a Hash of cached HTTP response headers for the paired request. 

Quindi, per rispondere alla tua domanda, intestazioni di richiesta HTTP e le intestazioni di risposta HTTP vengono memorizzati nel Rack :: Cache metastore. D'altra parte, lo storestore di Rack :: Cache memorizza interi corpi di risposta (ad esempio HTML).

Dal you can't use page caching reliably on Heroku, questo significa che si potrebbero utilizzare la cache azione e caching dei frammenti. Il caching di azioni e frammenti utilizza l'archivio cache di Rails (non la cache del rack). Ma se li hai impostati entrambi per utilizzare fisicamente lo stesso server memcached, entrambi contribuiranno all'uso della memoria. L'azione e il caching parziale memorizzano l'HTML effettivo.

Per ottenere un quadro più chiaro del vostro utilizzo effettivo, se si sta utilizzando memcachier eseguire il seguente comando per aprire un cruscotto di analisi nel tuo browser.

heroku addons:open memcachier 

Vedi this question per ulteriori informazioni su come ottenere statistiche memcached.

Answer 2

Ebbene, non è così facile rispondere.

Prima di tutto, probabilmente non archiviare nulla sul file system Heroku, in quanto non è modificabile. Pertanto è necessario memorizzare tutto in Memcache. Quindi sul piano gratuito verranno memorizzati 5/25mb di dati, inclusi sia le entità che i metadati.

Come la documentazione dicono (per lo stack Cedar):

Ogni banco prova ottiene il proprio file system effimera, con una nuova copia del codice più recente distribuito. Durante la sua vita, il dyno può usare il filesystem come un blocco temporaneo temporaneo, ma nessun file che scrive è visibile a nessun altro banco di prova (inclusi altri dynos nell'applicazione) e tutti i file scritti verranno scartati nel momento in cui il banco viene fermato o riavviato.

Pertanto, sì, l'utilizzo del filesystem sembra abbastanza valido, soprattutto se si utilizza un singolo banco.

Riguardo alla distinzione tra Rack :: Cache e Memcache: Memcache è un server che memorizza coppie chiave/valore con alcune proprietà aggiuntive aggiuntive in memoria. Il config.cache_store = :dalli_store configura Rails.cache che è un'astrazione sui diversi meccanismi di memorizzazione nella cache che è possibile utilizzare. È generale e puoi usarlo per l'archiviazione di chiavi/valori arbitrari, la memorizzazione di azioni e frammenti di cache.

Rack :: Cache invece è un sostituto di Varnish e consente di memorizzare intere richieste.