代码之家 › 专栏 › 技术社区 › John Topley

Rails的页面缓存与HTTP反向代理缓存

page-caching reverse-proxy http apache ruby-on-rails

1

John Topley · 技术社区 · 15 年前

我一直在追赶 Scaling Rails 尖叫声。在 episode 11 其中包括高级HTTP缓存(使用反向代理缓存,如Varnish和Squid等),他们建议仅在耗尽Rails应用程序(以及memcached等)中页面、操作和片段缓存的可能性后才考虑使用反向代理缓存,但这与此问题无关。

我不太明白的是,如何使用HTTP反向代理缓存可以为已经使用页面缓存的应用程序提供性能提升。为了简化问题,假设我说的是一个主机。

这是我对这两种技术如何工作的理解(也许我错了):

通过页面缓存,Rails进程最初被点击,然后生成一个静态HTML文件,该文件由Web服务器直接为后续请求提供服务,只要该请求的缓存有效。如果缓存已过期,则会再次命中Rails,并重新生成静态文件,其中更新的内容将为下一个请求做好准备。
使用HTTP反向代理缓存,当代理需要确定内容是否过时时,会命中Rails进程。这是使用各种HTTP头完成的,例如 ETag , Last-Modified 等等。如果内容是新的,那么Rails会使用未修改的HTTP 304响应代理,而代理将其缓存的内容提供给浏览器,或者更好地,使用自己的HTTP 304响应。如果内容过时,则Rails将更新的内容提供给代理服务器,代理服务器将其缓存,然后将其提供给浏览器。

如果我的理解是正确的,那么页面缓存不会减少对Rails进程的命中吗?不需要反复确定内容是否过时,这意味着比反向代理缓存性能更好。为什么要同时使用这两种技术?

4 回复 | 直到 15 年前

1

2

cwninja 15 年前

你是对的。

唯一需要考虑的原因是,如果您的Apache设置了Expires头文件。在这个配置中,代理可以从Apache上卸下一些负载。

尽管如此,ApacheStaticVsProxy缓存在Rails世界中基本上是无关紧要的。它们都是天文速度。

你将得到的好处将是你的无页面可缓存的东西。

我更喜欢使用代理缓存而不是页面缓存(ala heroku),但那只是我自己,还有一个离题。

2

1

M Nottingham 15 年前

在使用预处理MPM时,一个好的代理缓存实现(例如,squid、流量服务器)比Apache具有更大的可扩展性。如果您使用的是Worker MPM,那么Apache就可以了,但是在高负载(每秒几万个请求)下,代理的可伸缩性仍然要高得多。

3

1

Ev Dolzhenko 15 年前

例如,Varnish有一个特性,当对同一个URL(不在缓存中)的同时请求被排队时,只有单个/第一个请求实际到达后端。这可以防止一些在传统页面缓存场景中几乎不可能解决的讨厌的狗堆情况。

4

0

Railsmechanic 15 年前

在只有一个应用服务器的设置中使用反向代理似乎有点过分。在具有多个应用服务器的配置中,反向代理(例如Varnish等)是页面缓存最有效的方法。

考虑一个2个应用服务器的设置:

这个并发问题可以用反向代理来解决。