big*_*can 13 memcached ruby-on-rails ruby-on-rails-3
刚开始将缓存引入新的Rails应用程序.我们首先使用cache_store :memory_store在application.rb中
config.cache_store = :memory_store
然后,我通过NewRelic运行了一些性能测试,以查看模型缓存发生之前/之后的性能.
之后我将cache_store切换为使用:dalli_store,因为它是当前推荐的使用带有Rails的memcached的gem.
config.cache_store = :dalli_store
然后我在针对memcached的缓存测试之前/之后重新进行相同的操作.缓存与非缓存请求/响应之间仍有明显改善; 但是,memcached缓存的性能始终是标准Rails:memory_store的两倍(大致).
为了澄清,在这些测试期间,我将memcached服务器本地运行到rails web应用程序,以避免将混乱中的网络延迟问题添加到其中.
所有这些都让我想到了以下真正的问题.
它是典型的看到从更快的性能:memory_store比:dalli_store？
如果它不典型,除了从memcached获得适当性能所需的标准设置之外,是否还有一些"技巧"？
如果这是典型的,那么为什么人们首先在Rails上使用memcached和:dalli_store？这是一个可扩展的问题......？
Sha*_*ell 15
从rails缓存指南中了解memory_store:
此缓存存储将条目保存在同一Ruby进程的内存中.
对于某些基准测试,你可能会非常快.它不需要花费任何精力来阅读或写入任何其他类型的存储.缓存的东西就在那里时,它需要它.
但是,在它变得笨拙之前,你不能存储太多这样的信息.服务器的进程将增长,缓存将很快摆脱最早的缓存信息(此缓存的默认大小为32mb).
此外,在运行多个进程时,就像生产服务器一样,您将在每个进程中复制缓存的信息.例如,如果您的主页被缓存,则需要将其缓存在服务器上运行的每个进程上.
您还将遇到从服务器进程内的缓存手动过期的问题,因为您需要与所有正在运行的进程通信以使缓存的信息失效,或者让他们在访问之前检查信息是否过时.
通过使用memcached或redis之类的东西,您可以让所有服务器进程访问相同的缓存,并且您可以拥有更大的缓存,这意味着缓存的信息会变得过时.您可以向缓存写入一次,所有服务器进程都会受益,您可以清除一次,所有进程都知道它已被清除.
正如您所知,权衡是写入和读取缓存的性能,但在任何类型的系统上,与拥有更复杂的缓存存储相比,性能权衡不值得.
| 归档时间： |
|
| 查看次数： |
4453 次 |
| 最近记录： |