部署 从 rack-cache 到 varnish,200 倍性能提升达成!

chrisloong · 2014年09月04日 · 最后由 freedom_fish 回复于 2014年10月09日 · 7439 次阅读
本帖已被设为精华帖!

使用 ruby 开发 web 应用之所以高效,ruby 语法友好是一方面,另外一方面就是社区资源,涉及 web 应用场景的 gem 有很多。

比如连 HTTP 加速器HTTP accelerator这种产品,都有纯 ruby 的实现:rack-cache

使用起来,难以置信的简单:

require 'rack/cache'

use Rack::Cache,
  :verbose     => true,
  :metastore   => 'file:/var/cache/rack/meta',
  :entitystore => 'file:/var/cache/rack/body'

run app

我们的产品中,所有上传图片,都是存储在 MongoDB,而且通过rack-thumb实现图片缩放功能,通过 url 中指定图片尺寸,就能获取对应尺寸的图片。

通过 HTTP 加速器,一种尺寸的图片,只需要生成一次,以后就从加速器的缓存中返回。

最初就是用简单的 rack-cache 来做 HTTP 加速,但很快就遇到瓶颈,

首先是性能,使用 rack-cache 后,配置为硬盘存储,测试响应性能,仅提升 20%。将 rack-cache 的存储改为 heap 后,性能提升也不显著。

其次是拓展,rack-cache 是 rack 的插件,必须跟着 app 走。部署多几台 app,那它们之间的缓存是无法共享的,除非将存储改为 Memcached,但是用内存来缓存静态资源,太奢侈!

所以总体来说,rack-cache 性价比太低,在有规模的生产环境中用,很不划算。

所以不得已,还是要跳出 ruby 的圈子,找业内通用的方案,首选肯定是名气最大的varnish。 安装的是最新版 v4.0,官方提供 CentOS 安装的 rpm,所以安装很方便。

把存储配置为硬盘,测试响应性能,能带来 200 倍以上的性能提升,一个词来形容当时心情的话,那就是:惊喜。 通过对 vcl 的配置vcl-backends,支持多个 app 也很方便。

不过 varnish 的在转发 request 到 app 时,只有两种策略:循环和随机,没有类似 nginx 的负载均衡功能,不过这点缺失影响不大。

虽然 rack-cache 比较弱,但它有个优势:容易用。如果是小项目,可以先用,等遇到性能瓶颈,再升级方案,用 varnish。

我们的 SaaS 产品友好速搭在内测期,用户数量是固定的,用了 4 台 rack-cache。之后上线开放,发现性能跟不上,很快就换成 varnish,配合一台处理缩略图的 app。 部署 varnish 的那台机器,4000req/s 的性能,应付 1000rpm 以内的压力,绰绰有余,此外,cpu 和内存也都很稳定,果然名不虚传。

楼主好,看了之后有两个疑问。

  1. 同样是选择硬盘存储静态文件, varnishnginx 有 200 倍性能的提升?
  2. 楼主的 rack app server 是什么?

#1 楼 @hz_qiuyuanxin 1.不是和 nginx 比哟,而是比 rack-cache。 2.unicorn

#2 楼 @ChrisLoong 大概明白了。

楼主有没有考虑过,将部分服务器和带宽的钱,换做买像又拍云或者七牛这样的云存储服务,来转移图片对于硬件和带宽资源的消耗?

#3 楼 @hz_qiuyuanxin 用 IaaS,带宽、主机存储,已经很便宜了。 而且我们本身也是服务商,电商方面的,图片用云服务存,一是不够灵活,二是又多了一种成本核算。

我在之前的项目中对比过直接使用 nginx 做静态缓存和 nginx + varnish,后者没有任何优势(速度,内存,架构简洁),有兴趣的话,你们可以对比测试一下。

#5 楼 @quakewang 顶这个。除非 cache 和 web 逻辑很紧密,否则 nginx 自带缓存远远够用了。

LZ 的性能提升我表示怀疑,vanish 没那么神。。。。估计是你特定业务场景导致的一个巧合。

#5 楼 @quakewang :plus1: nginx 真是神器,比 varnish 快至少 2 倍。

#6 楼 @est 那时主要是想找替代 rack-cache 的产品,varnish 比 rack-cache 快上百倍是真的。 但经测试,varnish 被 nginx 甩开好远,正考虑把 varnish 那层去掉,直接在 nginx 缓存。

以前在学校时学的 Squid 不过听说 Vanish 更牛。

看起来 MongoDB 文件储存根本是没必要的啊,GridFS 这玩意太鸡肋了,mongoid4 直接就移除对它的支持勒……其实直接把所需要用到的尺寸直接转出来存到文件中直接丢给 nginx 不更简单……

#10 楼 @aptx4869 GridFS 用起来简单,方便对文件进行统一存储和管理。 比如在代码里,可以用 model 的属性访问到文件,写起来很顺手, 部署个 replica set,可靠性就有了。 存文件系统,要做的其它事就多咯。

只有两种策略:循环和随机

只能说你没看文档

#12 楼 @mojidongvcl-backends 的介绍文档,只提到 round-robin director 和 random director,还有其它的?

GridFS + varnish 看起来很高大上,难道不是 nginx 两行配置就搞定的事儿吗

只有两种策略:循环和随机, 没有类似nginx的负载均衡功能

不好意思帖掉了,补上。

轮循和随机只是负载均衡算法之一,所以说没有 nginx 的负载均衡功能是不正确的。

另外说你没看文档是说用 vcl 你可以简单的实现其它负载衡算法(url hash,ip hash,加权轮询等)

#14 楼 @hooopo 😄 nginx 的功力不够呀,一直当转发请求的 web server 用。

#15 楼 @mojidong :plus1: 学习了。

#2 楼 @ChrisLoong rack-cache 也就是一个 ruby 进程,性能肯定不会好的。而且 rack-cache 主要功能是加 Cache-Control 的生效和失效控制。你用 varnish 主要起什么作用呢?

😳 😳 星期五下午面试我的系统架构大大么?

#18 楼 @swachian 设置 http 协议里面的 Cache-Control,在 nginx 和 app 层面都可以做的。我们用 rack-cache 主要目的,是做 server 端缓存。产品里面的缩略图都是动态生成,启用 server 端缓存,一张图片的一个尺寸,就只需要生成一次。缓存命中了就能直接返回,没命中再将 request 转发到 app 生成缩略图。

#19 楼 @vngmin title 是虚的,实际就是总干活的。😄

#21 楼 @ChrisLoong :thumbsup: 以后要多向你学习。

问个问题,我看到 4000 request / s 那有没有一个小时内的统计? 因为这个不可以从 4000 累加的。

#23 楼 @freedom_fish 这个数据是用 apache ab 工具压测的,只是用来对比性能的参考。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册