12

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

config.cache_store = :memory_store

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

之后，我将 cache_store 切换为使用 :dalli_store，因为目前推荐将 memcached 与 Rails 一起使用。 

config.cache_store = :dalli_store

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

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

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

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

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

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

4

1 回答 1

15

从rails缓存指南中关于memory_store：

这个缓存存储将条目保存在同一个 Ruby 进程的内存中。

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

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

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

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

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

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

于 2013-09-11T15:20:36.933 回答