Memcached大小限制到底与文件系统实体库有什么关系？

Good afternoon,

I have Memcached hooked up in my app on Heroku. The limit for the free managed plan is 5MB for Memcached and 25MB for Memcachier. Being new to pretty much everything, I was just hoping for clarification of exactly what this represents.

我把Memcached连接到Heroku的应用程序中。免费托管计划的限制是Memcached为5MB,Memcachier为25MB。作为几乎所有事物的新手,我只是希望澄清这代表什么。

I have the DalliStore set up in my config file, and the typical options set up for Rack::Cache. My metastore is in Memcache and the entitiy store is set up on the filesystem.

我在配置文件中设置了DalliStore,并为Rack :: Cache设置了典型选项。我的Metastore在Memcache中,并且在文件系统上设置了权限存储。

Questions:

Does this mean that my 5/25MB limit is only being used by the meta information that I am storing about each cache fragment? This would mean that I'd be able to store a ton of information on just the free plans?

这是否意味着我的5 / 25MB限制仅被我存储的关于每个缓存片段的元信息使用?这意味着我能够在免费计划中存储大量信息吗?

What exactly is the breakdown / story between Rack::Cache and Memcache (via Dalli store?) Do they serve different purposes? Are they doing the same thing? i.e. is the following code redundant

Rack :: Cache和Memcache(通过Dalli商店)之间的细分/故事究竟是什么?它们是否有不同的用途?他们做同样的事吗?即以下代码是多余的

config.cache_store = :dalli_store

config.cache_store =:dalli_store

and

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

2 个解决方案

#1

I've been wrestling with similar issues.

我一直在努力解决类似的问题。

First of all, let's get our terminology straight.

首先,让我们的术语直截了当。

Memcached: a process running on a server somewhere (d is for daemon) that actually stores key-value pairs in memory.

Memcached:在某个服务器上运行的进程(d代表守护进程),它实际上将键值对存储在内存中。

cache_store: Rails cache storage (Rails.cache) with a single API which can be configured to use different Ruby software implementations. One setting for config.cache_store is :memory_store to use an in-memory implementation. Another setting is :dalli_store that specifies using the dalli gem, which under the hood makes a possibly-remote connection to your memcached server.

cache_store:使用单个API的Rails缓存存储(Rails.cache),可以配置为使用不同的Ruby软件实现。 config.cache_store的一个设置是:memory_store以使用内存中实现。另一个设置是:dalli_store,它指定使用dalli gem,它在引擎盖下与你的memcached服务器建立了一个可能远程的连接。

Dalli Store: I assume you mean the Rails cache backed by the dalli gem, which physically stores values in memcached.

Dalli Store:我认为你的意思是由dalli gem支持的Rails缓存,它在memcached中物理存储值。

Rack::Cache: Rack middleware that inserts headers (Expires, Cache-Control, ETag, etc.) into your HTTP responses, and also acts as a reverse proxy cache, handling requests before they hit the Rails stack when possible. See website.

Rack :: Cache:机架中间件,它将标头(Expires,Cache-Control,ETag等)插入到您的HTTP响应中,并且还充当反向代理缓存,在可能的情况下处理请求之前处理Rails堆栈。见网站。

In order for Rack::Cache to handle requests before they hit the Rails stack and the rest of your app, it must store responses + metadata somewhere. Where it stores things are configured by the config.action_dispatch.rack_cache = { ... } setting.

为了让Rack :: Cache在它们到达Rails堆栈和应用程序的其余部分之前处理请求,它必须在某处存储响应+元数据。它存储的位置由config.action_dispatch.rack_cache = {...}设置配置。

Notice, this is a different setting from config.cache_store = :dalli_store. They don't have to be related. I think this is where a lot of confusion comes from. In practice, though, we may want them both to use memcached, which means using the dalli implementation. However, they each have their own Dalli::Client instance. (Also, your session_store could be related, but doesn't have to be.)

请注意,这是与config.cache_store =:dalli_store不同的设置。他们没有必要相关。我认为这是很多混乱的地方。但实际上,我们可能希望它们都使用memcached,这意味着使用dalli实现。但是,它们每个都有自己的Dalli :: Client实例。 (另外,您的session_store可能是相关的,但不一定是。)

The Heroku cedar stack has an ephemeral file system that cannot be shared among dynos. However, Heroku themselves recommend using tmp file storage with Rack::Cache for the entitystore only, with memcached used for the metastore.

Heroku雪松堆栈有一个短暂的文件系统,不能在dynos之间共享。但是,Heroku自己建议仅对实体库使用带有Rack :: Cache的tmp文件存储,而memcached用于Metastore。

As for what actually gets stored in the Rack::Cache metastore, these are the docs from rack-cache v1.2 Rack::Cache::MetaStore class:

至于实际存储在Rack :: Cache Metastore中的内容,这些是来自rack-cache v1.2 Rack :: Cache :: MetaStore类的文档:

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.

So to answer your question, HTTP request headers and HTTP response headers are stored in the Rack::Cache metastore. On the other hand, the Rack::Cache entitystore stores entire response bodies (i.e. HTML).

因此,为了回答您的问题,HTTP请求标头和HTTP响应标头存储在Rack :: Cache Metastore中。另一方面,Rack :: Cache实体库存储整个响应主体(即HTML)。

Since you can't use page caching reliably on Heroku, this means you might be using action caching and fragment caching. Action and fragment caching use your Rails cache store (not rack cache). But if you've set them both to physically use the same memcached server, they'll both contribute to memory use. Action and partial caching store the actual HTML.

由于您无法在Heroku上可靠地使用页面缓存,这意味着您可能正在使用操作缓存和片段缓存。操作和片段缓存使用您的Rails缓存存储(而不是机架缓存)。但是如果你将它们都设置为物理上使用相同的memcached服务器,它们都会有助于内存使用。操作和部分缓存存储实际的HTML。

To get more insight of your actual usage, if you're using memcachier run the following command to open up an analytics dashboard in your browser.

为了更深入地了解您的实际使用情况,如果您正在使用memcachier,请运行以下命令在浏览器中打开分析仪表板。

heroku addons:open memcachier

See this question for more info about getting memcached stats.

有关获取memcached统计信息的详细信息,请参阅此问题。

#2

Well, this is not so easy to answer.

嗯,这不容易回答。

First of all, you will likely not be storing anything on the Heroku filesystem, ~~as it is not writeable~~. Therefore you should store everything in Memcache. So on the free plan you will store 5/25mb of data including both entities and metadata.

首先,您可能不会在Heroku文件系统上存储任何内容,因为它不可写。因此,您应该将所有内容存储在Memcache中。因此,在免费计划中,您将存储5 / 25mb的数据,包括实体和元数据。

As the docs say (for the Cedar stack):

正如文档所说(对于Cedar堆栈):

Each dyno gets its own ephemeral filesystem, with a fresh copy of the most recently deployed code. During its lifetime the dyno can use the filesystem as a temporary scratchpad, but no files it writes are visible to any other dyno (including other dynos in the application) and any files written will be discarded the moment the dyno is stopped or restarted.

每个dyno都有自己的短暂文件系统,并带有最近部署的代码的新副本。在其生命周期中,dyno可以将文件系统用作临时暂存器,但是其写入的文件对于任何其他dyno(包括应用程序中的其他dyno)都不可见,并且在dyno停止或重新启动时将写入所有写入的文件。

Therefore, yes using the filesystem seems fairly viable, especially if you are using a single dyno.

因此,使用文件系统似乎相当可行,特别是如果您使用单个dyno。

Regarding the distinction between Rack::Cache and Memcache: Memcache is a server that stores key/value pairs with some additional nice properties in memory. The config.cache_store = :dalli_store configures Rails.cache which is an abstraction over the different caching mechanisms that one could use. It is general and you can use it for arbitrary key/value storage, action and fragment caching.

关于Rack :: Cache和Memcache之间的区别:Memcache是一个存储键/值对的服务器,在内存中有一些额外的好属性。 config.cache_store =:dalli_store配置Rails.cache,它是对可以使用的不同缓存机制的抽象。它是通用的,您可以将它用于任意键/值存储,操作和片段缓存。

Rack::Cache on the other hand is a replacement for Varnish and allows you to cache whole requests.

另一方面,Rack :: Cache是Varnish的替代品,允许您缓存整个请求。

#1