ruby-on-rails - 为什么是 :memory_store cache faster than :dalli_store for memcached? 我应该坚持使用 :memory_store?

Question

刚刚开始在一个新的 Rails 应用程序中引入缓存。我们首先在application.rb中设置cache_store使用:memory_store

config.cache_store = :memory_store

然后我通过 NewRelic 进行了一些性能测试，以查看模型缓存发生之前/之后的性能。

之后，我将 cache_store 切换为使用 :dalli_store，因为它是当前推荐的将 memcached 与 Rails 结合使用的 gem。

config.cache_store = :dalli_store

然后我在针对 memcached 的缓存测试之前/之后重新运行相同的测试。缓存和非缓存的请求/响应之间仍然有明显的改进；然而，memcached 缓存的性能始终是标准 Rails:memory_store 的两倍(大致)。

为了澄清起见，在这些测试期间，我在 rails web 应用程序本地运行 memcached 服务器，以避免在混合中添加网络延迟问题。

所有这些都让我想到了以下真正的问题。

从 :memory_store 看到比 :dalli_store 更快的性能是典型的吗？

如果它不是典型的，除了从 memcached 获得适当性能所需的标准设置之外，还有一些我不知道的“技巧”吗？

如果这是典型的，那么为什么人们首先在 Rails 上使用 memcached 和 :dalli_store？这是一个可扩展性的问题，等等......？

Answer 1

来自关于 memory_store 的 rails 缓存指南:

This cache store keeps entries in memory in the same Ruby process.

对于某些基准测试，您会期望它非常快。它不必付出任何努力来读取或写入任何其他类型的存储。缓存的东西在需要时就在那里。

但是，在变得笨拙之前，您不能存储太多这样的信息。您的服务器的进程将增长，您的缓存将很快清除最旧的缓存信息(此缓存的默认大小为 32mb)。

此外，如果运行多个进程，就像生产服务器一样，您将在每个进程中复制缓存信息。例如，如果您的主页被缓存，您需要在服务器上运行的每个进程上缓存它。

您还会遇到手动从服务器进程内的缓存中过期的问题，因为您需要与所有正在运行的进程通信以使缓存的信息过期，或者让他们在访问信息之前检查信息是否过时。

通过使用诸如 memcached 或 redis 之类的东西，您可以让所有服务器进程访问相同的缓存，并且您可以获得更大的缓存，这意味着缓存信息变得陈旧的频率要低得多。您可以写入一次缓存，所有服务器进程都会受益，您可以清除一次，所有进程都知道它已被清除。

正如您所确定的，权衡是写入和读取缓存的性能，但在任何大小的系统上，与拥有更复杂的缓存存储相比，性能权衡都不值得。