我一直在努力解决类似的问题。
首先,让我们弄清楚我们的术语。
- Memcached:在某处的服务器上运行的进程(d 代表守护进程),它实际上将键值对存储在内存中。
- cache_store:Rails 缓存存储(
Rails.cache
),带有一个 API,可以配置为使用不同的 Ruby 软件实现。一种设置config.cache_store
是:memory_store
使用内存中的实现。另一个设置是:dalli_store
指定使用 dalli gem,它在后台与您的 memcached 服务器建立可能的远程连接。
- Dalli Store:我假设您的意思是由 dalli gem 支持的 Rails 缓存,它将值物理存储在 memcached 中。
- Rack::Cache:Rack 中间件,将标头(Expires、Cache-Control、ETag 等)插入到 HTTP 响应中,还充当反向代理缓存,尽可能在请求到达 Rails 堆栈之前对其进行处理。见网站。
为了让 Rack::Cache 在请求到达 Rails 堆栈和应用程序的其余部分之前处理它们,它必须在某处存储响应 + 元数据。它存储东西的位置由config.action_dispatch.rack_cache = { ... }
设置配置。
请注意,这是与不同的设置config.cache_store = :dalli_store
。他们不必是相关的。我认为这就是很多混乱的来源。但在实践中,我们可能希望它们都使用 memcached,这意味着使用 dalli 实现。但是,它们每个都有自己的Dalli::Client
实例。(此外,您的 session_store 可能是相关的,但不一定是。)
Heroku cedar 堆栈有一个临时文件系统,无法在 dyno 之间共享。但是,Heroku 自己建议仅使用带有 Rack::Cache的tmp 文件存储entitystore
,而将 memcached 用于metastore
.
至于实际存储在 Rack::Cache 元存储中的内容,这些是rack-cache v1.2Rack::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.
因此,为了回答您的问题,HTTP 请求标头和 HTTP 响应标头存储在 Rack::Cache 元存储中。另一方面,Rack::Cache entitystore 存储整个响应体(即 HTML)。
由于您不能在 Heroku 上可靠地使用页面缓存,这意味着您可能正在使用动作缓存和片段缓存。动作和片段缓存使用您的 Rails 缓存存储(不是机架缓存)。但是,如果您将它们都设置为物理上使用同一个 memcached 服务器,它们都将有助于内存使用。动作和部分缓存存储实际的 HTML。
为了更深入地了解您的实际使用情况,如果您使用 memcachier,请运行以下命令在浏览器中打开分析仪表板。
heroku addons:open memcachier
有关获取 memcached 统计信息的更多信息,请参阅此问题。