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:以上测试结果的数据受系统环境和应用程序参数的影响，因此不一定很准确，仅供参考。
