赞
踩
nginx并不能从根本上提升服务器性能,如果是单体应用可能还会导致服务器性能下降,nginx更偏向于解决服务器扩容和分布式系统部署,此处比较几个常用的缓存
以下均为转载
Varnish、Squid、Ngx_cache性能测试对比
一:概括:
varnish与squid是在业内比较主流的web缓存加速技术,与传统的web加速技术apache cache和nginx cache相比,做的更专业,性能更出众!对于两款软件的简介这里就不多做介绍,网上有很多的资料与文档,感兴趣的同学可以自己看看。下面就一起看看他们的性能和抗压情况吧!
1.工作原理与性能对比
(1)Varnish:
Varnish缓存加速原理:Varnish把数据缓存到服务器的内存中(通过-s file选项也可以先存到磁盘中),用户访问时直接从内存中的缓存数据读取,因此非常快。它可以设置0~60秒的精确缓存时间,不过32位的机器支持的缓存文件最大为2 GB。Varnish的状态机设计不仅巧妙,结构也很清晰,利用二叉堆管理缓存文件,即可达到随时删除的目的。
优点:varnish由于是采用多线程的方式运行,所以它的系统资源利用率要比squid强(squid采用单进程耗1核CPU),但在高并发下它的CPU、Mem、IO资源消耗也比squid严重。varnish的TCP连接与释放比squid更快一些,因此在同样的负载情况下支持更高的并发连接数。由于客户是从内存中读取缓存,因此比squid硬盘级的缓存速度更快。Varnish支持管理端口通过正则表达式来清楚缓存。Varnish总体来说适合高质量大流量的缓存加速(如静态页面和小文件等)。
(2)Squid:
Squid缓存加速原理:支持正向代理、透明代理、反向代理,它采用硬盘级的缓存技术,将用户的请求文件缓存到本地磁盘中能够缓存更多的内容,每G磁盘空间需要32M的内存,因此512M内存的系统能支持16G的磁盘缓存。
优点:squid采用单进程使用单核CPU,利用资源的问题上不如varnish合理,但同时在资源消耗上要比varnish小。由于是采用硬盘做缓存,所以数据的完整性上要比varnish强,因为缓存到varnish内存上的数据是易失的,一旦varnish进程hang、crash或者重启,缓存的数据都会从内存中释放出来,此时所有请求都会发送到后端服务器,在高并发下会给后端的server造成很大的压力。Squid很多人说命中比较低,所以需要多个服务器同时来缓存才能发挥作用。总体来说squid缓存的体系比较大成本高,适合大文件、流媒体等数据的缓存。
(3)Nginx_cache:
Nginx缓存加速原理:nginx在0.7.48版本以后开始支持类似squid的缓存功能,他通过proxy_cache模块与fastcgi_cache模块实现对web的静态页面加速和对fastcgi动态程序的缓存加速,nginx_cache缓存是把URL及相关组合当作Key,用md5编码哈希后保存在硬盘上,所以它可以支持任意URL链接,同时也支持404/301/302这样的非200状态码。同时nginx_cache将缓存到的数据直接存放到内存文件系统中加快访问速度,同时内存文件系统与磁盘做硬link,不分热点与非热点数据,内存占用率不是最优的。Nginx_cache把热点文件分层缓存,一般使用时将cache目录放置与内存文件系统中。
优点:Nginx已经具备Squid所拥有的Web缓存加速功能、通过ngx_cache_purge模块清除指定URL缓存的功能。而在性能上,Nginx对多核CPU的利用,胜过Squid不少。另外,在反向代理、负载均衡、健康检查、后端服务器故障转移、Rewrite重写、易用性上,Nginx也比Squid强大得多。这使得一台Nginx可以同时作为“负载均衡服务器”与“Web缓存服务器”来使用。
二:测试要求:
(1)要求与环境:
要求:对Nginx源站中的一个大小为20K左右的静态页面进行压力测试。
环境(硬件):缓存服务器为HP DL360 G5,内存:8G,CPU:单颗Intel(R) Xeon CPU E5506 2.13GHz 4核,硬盘:160G scsi接口。
环境(软件):缓存和源站系统均为centOS 6.4 64位,squid版本为2.6-STABLE23(官方最稳定),varnish版本为最新的3.0.2。nginx
源站:Nginx服务器,HP DL160 G6,内存8G,CPU:单颗 Intel Xeon CPU E5504 2.00GHz 4核,硬盘:160G scsi接口。
预计结果:在大量的论坛和web缓存加速的博文中,都说varnish比squid更强,支持的并发更高,性能更稳定。而nginx_cahce并不是专业的缓存加速软件,理论上并没有squid和varnish支持的好。根据varnish的特点(小文件、静态页面加速效果更好),理论上应该是varnish的特点更适合这个应用场景。但我们来看看实际是不是这样呢?
下面我们就来利用web压力测试软件webbench来进行测试吧。
如图,-c选项是客户端的请求个数,-t为时间,默认单位是秒。如图意义为,在30秒内对http://10.20.216.56/tz.htm进行1000次HTTP(GET)请求。Speed的值为每分钟访问页面的数量,Requests为成功和失败访问的次数。
(2)测试结果:
压力情况
缓存类型
| 30秒内500个客户端请求
| 30秒内1000个客户端请求
| 30秒内3000个客户端请求
| 30秒内5000个客户端请求
| 30秒内10000个客户端请求
|
Squid2.6-STABLE23-ufs存储
| 40.5万次\100%
81.0万
pages/min
| 40.7万次\100%
81.4万pages/min
| 40.8万次\100%
81.7万pages/min
| 40.5万次\100%
81.1万pages/min
| 40.6万\99.9%
82.5万pages/min
|
Squid2.6-STABLE23-coss存储
| 44.2万次\100%
86.1万
pages/min
| 45.2万次\100%
87.1万
pages/min
| 44.3万次\100%
89.3万
pages/min
| 44.5万次\100%
87.3万
pages/min
| 44.1万\99.9%
86.3万
pages/min
|
Varnish-3.0.2
| 70.1万次\100%
140万pages/min
| 69.7万次\100%
139.4万pages/min
| 69.9万\99.66%
140.2万pages/min
| 70.2万\99.26%
141.5万pages/min
| 68.9万\93.88%
148.5万pages/min
|
Nginx_cache
| 60.8万次\100%
121.6万
pages/min
| 63.1万次\100%
125.9万
pages/min
| 67.5万\99.99%
134.5万
pages/min
| 72.7万\99.99%
145.5万
pages/min
| 73.4万\99.82%
148.7万
pages/min
|
Nginx源站
| 66.1万次\100%
133.0万
pages/min
| 63.4万次\100%
127.0万
pages/min
| 80.1万\98.8%
162.1万
pages/min
| 82.2万\96.9%
169.7万
pages/min
| 89.4万\93.8%
191.6万
pages/min
|
综上表所述:
1.Varnish:在500-1000并发情况下,varnish的性能明显好于对手,很好的起到了缓存加速的目的并且大大减轻了源站的压力,但随着访问量的增加从3000以上并发开始,varnish的性能开始下滑,访问成功率下降、404错误失败增加、系统CPU负载同样严重。并没有预期的效果那么出众。
Varnish的关键配置文件如下:
varnishd -u varnish -g varnish -f /usr/local/varnish/etc/vcl.conf -a 10.20.216.56:80 -s file,/usr/local/varnish/cache/varnish_cache.data,4G -w 5,51200,30 -t 3600 -T 10.20.216.56:3000
-s:制定存储类型和存储目录文件大小。
-w:min,max,timeout 指定varnish的工作线程数。
-t:指定默认ttl值。
2.Squid:基于ufs的传统存储方式,随着访问量的增高性能并没有明显的变化(系统负载的情况也比较平稳),可是在10000的高并发下还是出现了失败的情况;基于coss的适合小文件缓存的存储方式,效果比ufs稍稍的强一些但提升的不是很大,大概提升不到10%。总体来看,squid不论是采用哪种存储方式存数据,加速的效果都没有源站好,但分担负载的作用还是能充分体现的。和预期结果还是有偏差。
Squid的关键配置如下:
cache_mem 1024 MB #指定squid可以使用的内存的理想值
cache_swap_low 80 #缓存空间允许使用的最小空间百分比
cache_swap_high 90 #缓存空间允许使用的最大空间百分比
maximum_object_size_in_memory 100 KB #内存缓存的最大文件
cache_dir ufs /usr/local/squid/cache 20480 16 256 max-size=204800 #设置磁盘缓存工作方式,工作路径,大小单位MB,一级HASH的目录数量,二级HASH的目录数量。
3.Nginx_cache:nginx的proxy_cache缓存加速模块,虽然在500-1000左右并发的情况下没有varnish卓越,但在高并发3000以上的情况下性能还是比预期的要好,无论是在成功相应的请求次数上还是速度上,都比varnish和squid的性能更强更稳定。
Nginx_cache关键配置如下:
worker_processes 4; #指定进程的个数
worker_rlimit_nofile 65535; #文件句柄数,和系统单进程打开的文件数相同
events
{
use epoll;
worker_connections 65535; #定义单个进程的连接数
}
server_names_hash_bucket_size 128; #共同控制保存服务器名的HASH表
proxy_connect_timeout 5; #nginx和后端服务器连接超时时间
proxy_read_timeout 60; #连接成功后等候后端服务器响应时间,其实已经进入后端的排队等候处理
proxy_send_timeout 5; #后端服务器数据回传时间,就是在规定的时间内后端服务器必须传完所有的数据
proxy_buffer_size 16k; #代理请求缓存去,该缓存去间保存用户的头信息,以供nginx进行规则处理一般只要保能保存下头信息即可
proxy_buffers 4 64k; #告诉nginx保存单个用的几个buffer 最大用多少空间
proxy_busy_buffers_size 128k; #高负载下缓冲大小(proxy_buffers*2)
proxy_temp_file_write_size 128k; #设置缓存文件夹大小,如果大于该值,将从upstream 服务器传递请求,而不缓冲到磁盘上
概括总结:
由于需求是针对于50K以下的小文件,谁抗压能力更强加速效果更好,并且保障5个9以上的高可用性,为用户提供更好的体验。在500~1000左右的并发下,varnish的表现更出色。而在3000以上的并发情况下,Nginx_cache出乎意料,比varnish和squid的整体性能都要强。因此:
3000以下并发:varnish
3000以上并发:Nginx_cache
PS:以上测试结果的数据受系统环境和应用程序参数的影响,因此不一定很准确,仅供参考。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。