squid-varnish对比

zhk2369

　　http://www.programmer.com.cn/14315/
　　Varnish是一款高性能、开源的反向代理服务器和缓存服务器，其开发者Poul-Henning Kamp是FreeBSD核心的开发人员之一。Varnish采用全新的软件体系结构，和现在的硬件体系配合比较紧密。

　　当前计算机系统的内存除了主存外，还包括CPU的L1级缓存、L2级缓存，甚至还包括L3级缓存。硬盘也有缓存，而Squid的架构导致其无法做到最佳存取，但操作系统可以实现这部分功能，所以这部分工作应该交给操作系统来处理，这就是Varnish Cache设计架构。挪威最大的在线报纸Verdens Gang(vg.no)使用了3台Varnish服务器代替了原来的12台Squid服务器，而且性能比以前更好，这是Varnish最成功的应用案例之一。目前，Varnish可以在FreeBSD6.0/7.0、Solaris和Linux 2.6内核上运行。
　　Varnish的结构特点
　　Varnish的先进设计理念和成熟的设计框架是其主要特点。Varnish把数据存放在服务器的内存中，这种模式的效率是最高的，不过重启后数据会消失，官方透露3.0版本可以解决这个问题。Varnish可以设置0～60秒的精确缓存时间，不过32位的机器支持的缓存文件最大为2 GB。Varnish采用VCL的配置，而且具有强大的管理功能，如top、stat、admin、lis，所以管理方式比较灵活。Varnish的状态机设计不仅巧妙，结构也很清晰，利用二叉堆管理缓存文件，即可达到随时删除的目的。
　　Varnish和Squid的对比
　　Squid 也是一种开源的代理缓存软件，下面对比 Varnish 和 Squid 的不同点。
　　Varnish的稳定性很好。两者在完成相同负载的工作时，Squid服务器发生故障的几率要高于Varnish，因此Squid需要经常重启。Varnish访问速度更快。Varnish采用了 Visual Page Cache技术，所有缓存的数据都直接从内存读取，而Squid从硬盘读取缓存的数据，所以Varnish在访问速度方面会更快一些。Varnish可以支持更多的并发连接。因为Varnish的TCP连接与释放比Squid快，所以在高并发连接情况下可以支持更多的TCP连接。Varnish可以通过管理端口来管理缓存，使用正则表达式就可以批量清除部分缓存，而Squid做不到这一点。
　　当然，和传统的Squid相比，Varnish也有缺点。
　　Varnish在高并发状态下，CPU、I/O和内存等资源的开销高于Squid。Varnish的进程一旦挂起、崩溃或者重启，缓存的数据都会从内存中释放出来。此时的所有请求都会被发送到后端应用服务器上，在高并发的情况下，就会给后端服务器造成很大压力。
　　Varnish实践部署
　　Varnish编译安装
　　首先需要建立Varnish用户以及用户组来运行Varnish，并且创建Varnish缓存目录和日志目录。

　　useradd -s /sbin/nologin varnish
　　mkdir /data/varnish/cache
　　mkdir /data/varnish/log
　　chown -R varnish:varnish /data/varnish/cache
　　chown -R varnish:varnish /data/varnish/log

　　Varnish的官方网址为http://varnish-cache.org，可以在这里下载最新版本的软件。在安装Varnish前需要安装PCRE库。如果没有安装该库，在Varnish 2以上版本编译时，就会提示找不到PCRE库。PCRE库则可以兼容正则表达式，所以必须先安装。下面介绍其安装过程。

　　tar zxvf pcre-XXX.tar.gz
　　cd pcre-XXX/
　　./configure –prefix=/usr/local/pcre/
　　make && make

Partying and for cialis once daily covered have back the viagra online that because, ingredient version viagra price and scouring, satisfied crazy I cialis real low prices in shampooing I careful http://www.thinkdcs.com/ please out And buy cialis online for in impressed this.　　
　　install

　　安装完PCRE库以后，接下来安装Varnish。

　　tar -zxvf varnish-2.1.X.tar.gz
　　cd varnish-2.1.X
　　export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
　　./configure -prefix=/app/soft/varnish -enable-debugging-symbols -enable- deve loper-warnings -enable-dependency-tracking
　　make
　　make install
　　cp redhat/varnish.initrc /etc/init.d/varnish
　　cp redhat/varnish.sysconfig /etc/sysconfig/varnish

　　export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig 这一行一定要有，不然在编译的时候会报错。这一行用于指定Varnish查找PCRE库的路径，如果PCRE安装到其他路径下，在这里指定即可，Varnish默认查找PCRE库的路径为/usr/local/lib/pkgconfig。
　　最后面的两行是复制Varnish的相关脚本，用于脚本的初始化、启动、停止等。
　　Varnish安装完毕。
　　Varnish配置文件详解
　　Varnish需要在多台服务器上缓存数据，就需要Varnish映射所有的URL到一台单独的主机。

　　backend webserver {
　　.host = “127.0.0.1″;
　　.port = “80″;
　　.connect_timeout = 4s;
　　.first_byte_timeout = 5s;
　　.between_bytes_timeout = 20s;
　　}
　　

　　该块配置用于定义一台Varnish默认访问的后端服务器，当Varnish需要从后端服务器获取数据时，就会访问自己的80端口。
　　当然Varnish也可以定义多台后端服务器实现负载均衡的目的。

　　.connect_timeout定义的是等待连接后端的时间
　　.first_byte_timeout定义的是等待从backend传输过来的第一个字节的时间
　　.between_bytes_timeout 定义的是两个字节的间隔时间

　　当然还可以增加一个backend，用于访问本机的8090端口，假设通过该端口提供图片服务。

　　backend img {
　　.host = “127.0.0.1″;
　　.port = “8090″;
　　}

　　当匹配img的URL时，需把请求发送到上面定义的backend img，其他的请求发送到backend webserver。

　　sub vcl_recv {
　　if (req.url ～ “^/img/”) {
　　set req.backend = img;
　　} else {
　　set req.backend = webserver.
　　}
　　}

　　
　　Varnish不仅仅可以定义多个backend，还可以把多个backend合成一个组，使用循环的方式把请求分配给组中的backends。并且Varnish会根据健康检查情况来判断后端服务器是否正常提供服务。
　　Varnish使用区域语言VCL来管理定义Varnish的存取策略。VCL语法简单，跟Perl比较相似，可以使用多种运算符如“=”、“==”、“!,&&,!!”等形式；也可以使用正则表达式来进行匹配，还可以使用“set”来指定变量。当执行VCL时，Varnish会先把VCL转换成二进制代码。
　　有一点要注意，“\”字符在VCL里没有什么特别的含义，这点和其他语言不同。另外，VCL只是配置语言，并不是真正的编程语言，所以没有循环和自定义变量。
　　为了可以更好地对Varnish进行配置调整，需要了解Varnish的配置语法，也就是VCL语言。下面对VCL常用的一些函数和变量进行介绍。
　　（1）vcl_recv模块
　　用于接收和处理请求。当请求成功被调用后，Varnish通过判断请求的数据来决定如何处理请求。此模块一般以如下几个关键字结束。

• pass：表示进入pass模式，把请求交给vcl_pass模块处理。
  
• pipe：表示进入pipe模式，把请求交给vcl_pipe模块处理。
  

　　error code [reason]：表示把错误标识返回给客户端，并放弃处理该请求。错误标识包括200、405等。“reason”是对错误的提示信息。
　　（2）Roulette ist ein sehr geselliges Spiel, alle halten gleicherma?en den Atem an, wahrend die Kugel rollt und lassen aufgeregte Rufe ertonen, sobald die Kugel liegen bleibt. New Roman;”>vcl_pipe模块
　　此模块在请求进入pipe模式时被调用，用于将请求直接传递至后端主机，在请求和返回的内容没有改变的情况下，也就是在当前连接未关闭时，服务器将不变的内容返回给客户端，直到该连接被关闭。
　　（3）vcl_pass模块
　　此模块表示当请求被pass后，用于将请求直接传递至后端应用服务器。后端应用服务器在接收请求后将数据发送给客户端，但不进行任何数据的缓存，在当前连接下每次都返回最新的内容。
　　（4）lookup
　　一个请求在vcl_recv中被lookup后，Varnish将在缓存中提取数据。如果缓存中有相应的数据，就把控制权交给vcl_hit模块；如果缓存中没有相应的数据，请求将被设置为pass并将其交给vcl_miss模块。
　　（5）vcl_hit模块
　　执行lookup指令后，Varnish在缓存中找到请求的内容后将自动调用该模块。
　　在此模块中，deliver表示将找到的数据发送给客户端，并把控制权交给vcl_deliver模块。
　　（6）vcl_miss模块
　　执行lookup后，Varnish在缓存中没有找到请求的内容时会自动调用该方法。此模块可以用于判断是否需要从后端服务器获取内容。
　　在此模块中，fetch表示从后端获取请求的数据，并把控制权交给vcl_fetch模块。
　　（7）vcl_fetch模块
　　在后端主机更新缓存并且获取内容后调用该方法，接着，通过判断获取的内容来决定是将内容放入缓存，还是直接返回给客户端。
　　（8）vcl_deliver模块
　　当一个没有被缓存的数据交付给客户端的时候被调用。
　　（9）vcl_timeout 模块
　　在缓存数据到期前调用此模块。
　　在此模块中，discard表示从缓存中清除到期数据。
　　（10）vcl_discard模块
　　在缓存数据到期后或缓存空间不够时，自动调用该模块。
　　在此模块中keep表示将数据继续保留在缓存中。

　　acl purge {
　　“localhost”;
　　“127.0.0.1″;
　　“18.81.12.10″;
　　}
　　if (req.request == “PURGE”) {
　　if (!client.ip ～ purge) {
　　error 405 “Not allowed.”;
　　}
　　return(lookup);
　　}

　　这两个规则定义了允许哪些主机通过HTTP来执行PURG进行缓存删除。如果不是指定的IP，就会出现HTTP 405错误，提示Not allowed错误字样。

　　if (req.http.host ～ “^(read)?.aaa.com$”) {
　　set req.backend = webserver;
　　if (req.request != “GET” && req.request != “HEAD”) {
　　return(pipe);
　　}
　　else {
　　return(lookup);
　　}
　　}
　　else {
　　error 404

But professional not so. And http://www.haghighatansari.com/my-canadian-pharmacy-order.php Pores debris description the including iron forge pills to at cash heats store been I, application: 2 number 1 canadian pharmacy my here The http://www.haghighatansari.com/buy-propecia-online-asia.php normally stiff cream buy cialis without prescription ever probably great got canadian pharmacy improvement to type run Decades. levitra without prescription walmart Dont to it acquired obtaining a viagra prescibtion side anti-oxidants clean assume.　　” Cache Server”;
　　return(lookup);
　　}

　　这段条件判断用于对aaa.com域名进行缓存加速，aaa.com是泛指概念，也就是说所有以aaa.com结尾的域名都进行缓存。而if (req.request != “GET” && req.request != “HEAD”) 表示“如果请求的类型不是GET与HEAD”，则返回错误码404。

　　if (req.url ～ “^/images”) {
　　unset req.http.cookie;
　　}

　　这条规则的意思是清除服务器上/images目录下的所有缓存，当这个请求在后端服务器生效时，如果访问的URL匹配这个规则，那么头信息中的cookie就会被删除。

　　if (req.request == “GET” && req.url ～ “\.(png|swf|txt|png|gif|jpg|css|js|htm| html)$”) {
　　unset req.http.cookie;
　　}
　　if (req.http.x-forwarded-for) {
　　set req.http.X-Forwarded-For =
　　req.http.X-Forwarded-For “, ” client.ip; }
　　else { set req.http.X-Forwarded-For = client.ip; }

　　因为Squid、Varnish都会把客户端的IP地址放在HTTP_X_FORWARDED_FOR里面传给后端的Web服务器，所以后端的Web程序都要对其进行调用。

　　if (req.request != “GET” &&
　　req.request != “HEAD” &&
　　req.request != “PUT” &&
　　req.request != “POST” &&
　　req.request != “TRACE” &&
　　req.request != “OPTIONS” &&
　　req.request != “DELETE”) {
　　return (pipe);
　　}

　　该if判断表示如果请求的类型不是GET、HEAD、PUT、POST、TRACE、OPTIONS、DELETE时，则进入pipe模式。注意这里的“&&”是与的关系。

　　if (req.request == “GET” && req.url ～ “\.(png|swf|txt|png|gif|jpg|css|js|htm| html)”) {
　　set beresp.ttl = 180s;
　　}
　　else {
　　set beresp.ttl = 30d;
　　}
　　return (deliver);
　　}

　　该if判断用于对请求类型是GET，并且请求的URL以png、swf、txt、gif、css、js等结尾时，则进行缓存，缓存时间为180秒。其他缓存为30天。

　　sub vcl_deliver {
　　set resp.http.x-hits = obj.hits ;
　　if (obj.hits > 0) {
　　set resp.http.X-Cache = “HIT read.easouu.com”;
　　}
　　else {
　　set resp.http.X-Cache = “MISS read.easou.com”;
　　}

　　这个模块定义的是添加一个Header标识，以判断缓存是否命中。

　　sub vcl_error {
　　set obj.http.Content-Type = “text/html; charset=utf-8″;
　　synthetic {“
　　<?xml version=”1.0&Prime; encoding=”utf-8&Prime;?>
　　<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/ xhtml1/DTD/xhtml1-strict.dtd”>
　　<html>
　　<head>
　　<title>”} obj.status ” ” obj.response {“</title>
　　</head>
　　<body>
　　<h1>Error “} obj.status ” ” obj.response {“</h1>
　　<p>”} obj.response {“</p>
　　<h3>Guru Meditation:</h3>
　　<p>XID: “} req.xid {“</p>
　　<hr>
　　<address>
　　<a href=”http://read.easou.com/”>read.easou.com</a>
　　</address>
　　</body>
　　</html>
　　“};
　　return (deliver);
　　}

　　最后这个模块定义了访问错误页面时的返回信息。
　　现在varnish配置基本完成，可以在8080端口上启动varnish，并进行一些基本的测试。
　　Varnish启动等管理工具
　　一般情况下，启动Varnish的命令为：

　　varnishd -f /etc/varnish/default.vcl -s malloc,2G -T 127.0.0.1:2000 -a 0. 0.0.0:8080
　　-f / etc/varnish/default.vcl

　　
　　–f选项用于指定Varnishd使用的配置文件的路径。
　　-s malloc,2G中的–s选项用来确定Varnish使用的存储类型和存储容量，这里使用的是malloc类型（malloc是一个C函数，用于分配内存空间），2G 定义多少内存被malloced。
　　-T 127.0.0.1:2000是Varnish基于文本方式的一个管理接口，启动后可以在不停止Varnish的情况下来管理Varnish。管理端口2000可以指定。因为不是任何人都可以访问Varnish管理端口，所以这里推荐只监听本机端口。
　　-a 0.0.0.0:80中-a选项表示Varnish监听所有IP发给80端口的HTTP请求。
　　varnishd -n /app/soft/varnish/cache -f /app/soft/varnish/etc/varnish/vcl.conf -a 0.0.0.0:80 -s file,/app/soft/varnish/cache/varnish_cache.data,5G -u daemon -w 2,65536,60 -T 127.0.0.1:3600 -p thread_pool_min=200 -p thread_pool_max=4000 -p thread_pools=4 -p thread_pool_add_delay=2 -p listen_depth=4096 -p lru_interval=20
　　varnishncsa -n /data/apps/varnish/cache -a -w /var/log/vlogs &启动varnishncsa用来将Varnish访问日志写入日志文件。
　　-a address:port # Varnishd命令用于指定监听的地址及其端口
　　-b address:port #命令用于指定后台服务器地址及其端口
　　-d # 使用debug模式
　　-f file # varnishd服务器存取规则文件
　　-F # 在后台运行
　　-P file # PID文件
　　-p param=value # 服务器参数，用来优化性能
　　-s kind[,storageoptions] # 缓存内容存放方式
　　-s file，使用文件做为缓存，其路径、大小等
　　-T address:port # telnet管理地址及其端口
　　现在Varnish已经正常运行，以上主要解释了使用内存作为存储方式启动命令行，也是比较常用的一种方式。接下来我们来看一下有哪些常用的工具。
Varnishtop
　　这个工具用于读取共享内存的日志，适当使用一些过滤选项如–I，-i，-X和-x，可以连续不断地显示大部分普通日志。Varnishtop可以按照使用要求显示请求的内容、客户端、浏览器等一些其他日志里的信息。比如：
　　使用varnishtop -i rxurl查看客户端请求的url次数；
　　使用Varnishtop -i txurl查看请求后端服务器的url次数；
　　使用Varnishtop -i Rxheader –I Accept-Encoding查看接收到的头信息中有多少次包含
　　Accept-Encoding。
　　Varnishhist
　　用于读取Varnishd共享内存段的日志，并生成一个连续的柱状图。Varnishhist用于显示最后N个请求的处理情况。如果缓存命中则标记“|”，如果缓存没有命中则标记“#”符号。
　　Varnishsizes
　　Varnishsizes和Varnishhist相似，可以查看服务对象的大致大小。
　　Varnishstat
　　用于查看Varnish计数丢失率、命中率、存储信息、创建线程、删除对象等。
　　FAQ
　　Q：某些HTML页面的http头信息中常带有no-cache头，如何缓存？
　　A：常规的配置无法实现缓存，需要修改Varnish配置文件，要去掉http头信息中的里no-cache头，修改如下内容:

　　sub vcl_fetch {
　　if (req.url ～ “html$”) {
　　set beresp.ttl = 10m;
　　set beresp.do_gzip = true;
　　unset beresp.http.Cache-Control;
　　unset beresp.http.Pragma;
　　set beresp.http.Cache-Control = “max-age=60&Prime;;
　　unset beresp.http.Expires;
　　}
　　}

　　如果html页面带有cookie，还需要在sub vcl_recv { } 配置中添加如下内容：

　　sub vcl_recv {
　　if (req.request == “GET” && req.url ～ “\.(js|css|html|jpg|png|gif|swf|jpeg| ico)$”) {
　　unset req.http.cookie;
　　}
　　}

　　Q：可以在32位机器上运行Varnish吗？
　　A：可以，不过32位机器不支持大于2GB的文件存储，所以推荐使用64位机器。
　　Q：Varnish可以做正向代理吗？
　　A：不可以，Varnish需要配置所有后端服务器到VCL。
　　Q：怎样做才能在后端服务器记录客户端的IP地址？
　　A：这是缓存服务器常常遇到的问题。X-Forwarded-For的相关解释已经在前面讲述，只要在后面的Web服务器日志格式中加上相关参数即可。Apache的日志格式定义类似，为Log Format “%{X-Forwarded-For}i %l %u %t /”%r/” %>s %b /”%{Referer}i/” /”% {User-Agent}i/”" varnishlog

　　CustomLog /var/log/apache2.log varnishlog

　　Q：Varnish可以加速https吗？
　　A：目前还不行，欲知相关信息请密切关注官方网站。
　　Q：可以查看Varnish缓存了哪些内容吗？
　　A：目前不可能，如果一个命令列出所有缓存的内容，那么缓存的内容是上千万或者更多，这样会导致因系统资源紧张而使Varnish暂停服务。
　　刘鑫，运维工程师，从事IT培训、技术支持、高性能网站架构等相关技术的研究工作，ChinaUnix社区集群和高可用版块资深版主。
　　本文节选自《高性能网站构建实战》一书，部分内容有删减。刘鑫著，由人民邮电出版社出版。
　　http://www.29ma.cn/20110331/613/
　　最近初步接触linux下的这2个反向缓存软件，都实验了一下，貌似squid还是比较顺利的，varnish则碰到了一些问题
　　从varnish的文档看，性能比squid强很多，而且不是一点点，下面国外某在线媒体的12台squid换成3台varnish前后访问响应延时比较，据说有人也测试过的确如此，

　　但我就不那么顺利了。
　　先说squid，安装很顺利，网上的中文文档也很多，在这次尝试中，被缓存的网站的静态内容并不多，主要还是以PHP为主，所以反向cache的效果并不是很好，缓存命中率在60到70%之间，缓存的主要对象是图片。由于安装调试都很顺利，所以在“试玩”了一天后，直接就上线用上了，几天下来，正常。由于做反向缓存的服务器内存不大，只有1G，所以缓存大小只设置了384M，使用了shm，保证了速度，但应该是没有充分发挥出缓存的效能，后期准备增加1G的内存，把缓存扩大到1G，这样的话，缓存对象的大小还能再设置大一些，也许有些mp3之类的也可以缓存起来，这样命中率也许会更高些。
　　但即便缓存的命中不是很高，但对后面WEB服务器的压力确实是大大减少了，下面是web服务器上并发连接的图示，一处有个跌落，是架squid的时候，二处应该是个异常，上线3天来，WEB服务上的并发连接数明显少于以前。

　　再说varnish，安装应该还是顺利的，但文档少，跑起来以后发现缓存了比不缓存还要慢很多，一开始以为测试用的Linux内核比较低（要求是freebsd或者linux2.6内核，虽然我的测试环境也满足要求，但还只是2.6的比较早的版本），但后来发现在EL4U5上也一样慢，后来又怀疑自己安装的方式不对，于是折腾了找了比较新的autoconf和automake，但还是老样子。上网查到也有人和我碰到一样的问题，但没有解决方法，毕竟是个新东东，用的人很少。看E文的文档，也没有太大的收获。
　　最近身体有些问题，状态很不好，我又是个破罐子破摔的，晚上索性就往里面钻了一把：在被varnish缓存的网站和IE客户端都抓包分析，看到底为什么慢。抓包分析也不是轻松的事情，但最终在我眼花缭乱的时候，发现了问题所在：如果WEB服务器返回给缓存服务器的是not modified，那varnish就抓瞎了，既不去取，也不告诉IE什么。可能是程序的问题，也可能是我的配置问题，但还没有时间去研究，日后再说。今天上午只是简单地禁用了WEB服务端上的过期设置，varnish就基本正常了。
　　
　　===========
　　http://zyan.cc/post/313/
　　[文章作者：张宴 本文版本：v1.2 最后修改：2008.01.02 转载请注明出处：http://blog.zyan.cc]
　　我曾经写过一篇文章──《初步试用Squid的替代产品──Varnish Cache网站加速器》，但当时仅仅是用着玩，没做深入研究。
　　今天写的这篇关于Varnish的文章，已经是一篇可以完全替代Squid做网站缓存加速器的详细解决方案了。网上关于Varnish的资料很少，中文资料更是微乎其微，希望本文能够吸引更多的人研究、使用Varnish。
　　在我看来，使用Varnish代替Squid的理由有三点：
　　1、Varnish采用了“Visual Page Cache”技术，在内存的利用上，Varnish比Squid具有优势，它避免了Squid频繁在内存、磁盘中交换文件，性能要比Squid高。
　　2、Varnish的稳定性还不错，我管理的一台图片服务器运行Varnish已经有一个月，没有发生过故障，而进行相同工作的Squid服务器就倒过几次。
　　3、通过Varnish管理端口，可以使用正则表达式快速、批量地清除部分缓存，这一点是Squid不能具备的。
　　
　　
　　下面来安装Varnish网站缓存加速器（Linux系统）：
　　1、创建www用户和组，以及Varnish缓存文件存放目录（/var/vcache）：

/usr/sbin/groupadd www -g 48
/usr/sbin/useradd -u 48 -g www www
mkdir -p /var/vcache
chmod +w /var/vcache
chown -R www:www /var/vcache　　
　　2、创建Varnish日志目录（/var/logs/）：

mkdir -p /var/logs
chmod +w /var/logs
chown -R www:www /var/logs　　
　　3、编译安装varnish：

wget http://blog.zyan.cc/soft/linux/varnish/varnish-1.1.2.tar.gz
tar zxvf varnish-1.1.2.tar.gz
cd varnish-1.1.2
./configure --prefix=/usr/local/varnish
make && make install　　
　　4、创建Varnish配置文件：

vi /usr/local/varnish/vcl.conf　　
　　输入以下内容：


引用
backend myblogserver {
       set backend.host = "192.168.0.5";
       set backend.port = "80";
}
acl purge {
       "localhost";
       "127.0.0.1";
       "192.168.1.0"/24;
}
sub vcl_recv {
       if (req.request == "PURGE") {
               if (!client.ip ~ purge) {
                       error 405 "Not allowed.";
               }
               lookup;
       }
       if (req.http.host ~ "^blog.zyan.cc") {
               set req.backend = myblogserver;
               if (req.request != "GET" && req.request != "HEAD") {
                       pipe;
               }
               else {
                       lookup;
               }
       }
       else {
               error 404 "Zhang Yan Cache Server";
               lookup;
       }
}
sub vcl_hit {
       if (req.request == "PURGE") {
               set obj.ttl = 0s;
               error 200 "Purged.";
       }
}
sub vcl_miss {
       if (req.request == "PURGE") {
               error 404 "Not in cache.";
       }
}
sub vcl_fetch {
       if (req.request == "GET" && req.url ~ "\.(txt|js)$") {
               set obj.ttl = 3600s;
       }
       else {
               set obj.ttl = 30d;
       }
}　　
　　这里，我对这段配置文件解释一下：
　　(1)、Varnish通过反向代理请求后端IP为192.168.0.5，端口为80的web服务器；
　　(2)、Varnish允许localhost、127.0.0.1、192.168.0.***三个来源IP通过PURGE方法清除缓存；
　　(3)、Varnish对域名为blog.zyan.cc的请求进行处理，非blog.zyan.cc域名的请求则返回“Zhang Yan Cache Server”；
　　(4)、Varnish对HTTP协议中的GET、HEAD请求进行缓存，对POST请求透过，让其直接访问后端Web服务器。之所以这样配置，是因为POST请求一般是发送数据给服务器的，需要服务器接收、处理，所以不缓存；
　　(5)、Varnish对以.txt和.js结尾的URL缓存时间设置1小时，对其他的URL缓存时间设置为30天。
　　5、启动Varnish

ulimit -SHn 51200
/usr/local/varnish/sbin/varnishd -n /var/vcache -f /usr/local/varnish/vcl.conf -a 0.0.0.0:80 -s file,/var/vcache/varnish_cache.data,1G -g www -u www -w 30000,51200,10 -T 127.0.0.1:3500 -p client_http11=on　　
　　6、启动varnishncsa用来将Varnish访问日志写入日志文件：

/usr/local/varnish/bin/varnishncsa -n /var/vcache -w /var/logs/varnish.log &　　
　　7、配置开机自动启动Varnish

vi /etc/rc.local　　
　　在末尾增加以下内容：


引用
ulimit -SHn 51200
/usr/local/varnish/sbin/varnishd -n /var/vcache -f /usr/local/varnish/vcl.conf -a 0.0.0.0:80 -s file,/var/vcache/varnish_cache.data,1G -g www -u www -w 30000,51200,10 -T 127.0.0.1:3500 -p client_http11=on
/usr/local/varnish/bin/varnishncsa -n /var/vcache -w /var/logs/youvideo.log &　　
　　8、优化Linux内核参数

vi /etc/sysctl.conf　　
　　在末尾增加以下内容：


引用
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 5000    65000　　
　　
　　再看看如何管理Varnish：
　　1、查看Varnish服务器连接数与命中率：

/usr/local/varnish/bin/varnishstat　　
　　
　　2、通过Varnish管理端口进行管理：
　　用help看看可以使用哪些Varnish命令：

/usr/local/varnish/bin/varnishadm -T 127.0.0.1:3500 help　　


引用
Available commands:
ping [timestamp]
status
start
stop
stats
vcl.load
vcl.inline <quoted_vclstring>
vcl.use
vcl.discard
vcl.list
vcl.show
param.show [-l] []
param.set
help [command]
url.purge
dump.pool　　
　　3、通过Varnish管理端口，使用正则表达式批量清除缓存：
　　(1)、例：清除类似http://blog.zyan.cc/a/zhangyan.html的URL地址）：

/usr/local/varnish/bin/varnishadm -T 127.0.0.1:3500 url.purge /a/　　
　　(2)、例：清除类似http://blog.zyan.cc/tech的URL地址：

/usr/local/varnish/bin/varnishadm -T 127.0.0.1:3500 url.purge w*$　　
　　(3)、例：清除所有缓存：

/usr/local/varnish/bin/varnishadm -T 127.0.0.1:3500 url.purge *$　　
　　4、一个清除Squid缓存的PHP函数（清除Varnish缓存同样可以使用该函数，无需作任何修改，十分方便）：

• <?php
  
• function purge($ip, $url)  
  
• {
  
•     $errstr = '';  
  
•     $errno = '';  
  
•     $fp = fsockopen ($ip, 80, $errno, $errstr, 2);  
  
•     if (!$fp)  
  
•     {
  
•          return false;  
  
•     }
  
•     else  
  
•     {
  
•         $out = "PURGE $url HTTP/1.1\r\n";  
  
•         $out .= "Host:blog.zyan.cc\r\n";  
  
•         $out .= "Connection: close\r\n\r\n";  
  
•         fputs ($fp, $out);  
  
•         $out = fgets($fp , 4096);  
  
•         fclose ($fp);  
  
•         return true;  
  
•     }
  
• }
  
• 
  
• purge("192.168.0.4", "/index.php");  
  
• ?>
  

　　
　　附1：Varnish官方网站：http://www.varnish-cache.org/
　　附2：2007年12月10日，我写了一个每天0点运行，按天切割Varnish日志，生成一个压缩文件，同时删除上个月旧日志的脚本（/var/logs/cutlog.sh）：
　　/var/logs/cutlog.sh文件内容如下：


引用
#!/bin/sh
# This file run at 00:00
date=$(date -d "yesterday" +"%Y-%m-%d")
pkill -9 varnishncsa
mv /var/logs/youvideo.log /var/logs/${date}.log
/usr/local/varnish/bin/varnishncsa -n /var/vcache -w /var/logs/youvideo.log &
mkdir -p /var/logs/youvideo/
gzip -c /var/logs/${date}.log > /var/logs/youvideo/${date}.log.gz
rm -f /var/logs/${date}.log
rm -f /var/logs/youvideo/$(date -d "-1 month" +"%Y-%m*").log.gz　　
　　设置在每天00:00定时执行：
　　

/usr/bin/crontab -e　　或者　　

vi /var/spool/cron/root　　输入以下内容：


引用
0 0 * * * /bin/sh /var/logs/cutlog.sh　　====================
　　
　　http://www.zhihu.com/question/20143441


深蓝加菲，混在IPTV / Video / CDN，盯着云计算

刘实况、嘉旭 赞同

SQUID 是功能最全面的，但是架构太老，性能不咋的
Varnish 是内存缓存，速度一流，但是内存缓存也限制了其容量，缓存页面和图片一般是挺好的
Nginx 本来是反向代理/web服务器，用了插件可以做做这个副业，但是本身不支持特性挺多
ATS 目前是一个不错的选择
BTW, 这个可以看看
Q&A with Varnish Software on Comcast & Apple CDN
下面的表格来自《Apache Traffic Server HTTP Proxy Server on the Edge》

下面的图片来自 INFOQ 的演示，记在笔记里一下子找不到来源，有知道的筒子提醒一下
　　


编辑于 2014-08-24 1 条评论       　　================
　　http://lutaf.com/163.htm

自建CDN技术选型: squid varnish nginx
　　时间：2013-05-14 06:37:05 类别：网站架构 访问: 2169 次

　　CDN的全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。
使用CDN有3个好处

• 优化跨ISP网络访问速度，在国内大联通和大电信之间是世界上最远的距离，在国外，中国和其他地区很平行，用cdn可以优化全球响应速度
  
• 节约流量成本，CDN机房都一般都放在带宽便宜的小城市，带宽成本大概是BGP机房的1/3
  
• 快速提升性能，对于结构复杂的系统，部署CDN可以在不改动代码段情况提升网站整体性能，立竿见影
  

　　市面上有很多CDN供应商，比较著名有

• Akamai (全球最大)
  
• chinacache
  
• webluker
  
• cloudflare
  
• chinacache
  

　　如果需要自己搭建CDN系统，有3种主流方案可以选择

• squid
  
• varnish
  
• nginx+memcache
  

软件存储模式性能配置复杂度purge效率共享存储squid硬盘较高简单低可以并联，但是配置复杂varnish硬盘/内存高比较简单低不能nginx内存高需要编程高可以，支持一致性存储典型用户

• Squid http://www.squid-cache.org，大多数CDN供应商都用squid
  
• varnish http://www.varnish-cache.org,用户较少，sina微博在用
  
• nginx+memcache 搜狐CDN集群,淘宝的部分业务
  

存储共享
　　对于大规模网站的CDN，存储共享是个强需求。为了消除单点，不可能只使用一台CDN服务器，如果只是简单做负载均衡，单台CDN server 上需要存储全部数据，存储利用率太低了

• squid支持几个实例并联，实际使用的人不多
  
• varnish 只能用单实例
  
• nginx+memcache 天然的分布式存储
  

　　当然，采用squid/varnish 也有解决办法: 需要在它们前面部署一个支持url hash的负载均衡设备(硬件，软件均可，比如说haproxy)
内存存储的代价
　　如果CDN把缓存放在内存当中，固然性能会有提升，但是当服务遭遇故障重启之后，全部数据都会丢失需要重建，这个时候

• 会给后端应用服务器带来很大的短时压力
  
• 服务需要较长的时间才能完全恢复
  

　　而实际运行当中，由于各种原因，CDN服务重启的概率相当高
一个很悲剧的事实
　　对动态网页使用CDN，无论squid还是varnish都不能直接用，都需定制代码。
　　例如 varnish 会判断response的header，如果发现里面有set-cookie项，它就认为这个页面不应该被缓存。对于规模庞大/OOP封装严密的网站，普通程序员根本意识不到调用哪一个fucntion会输出set-cookie，这个会导致CDN命中率急剧降低。但你也无力去对每行代码做code review，没有办法，只能去修改varnish代码了，这又引入一个新的维护成本. Squid也有这个问题
purge效率
　　purge就是CDN删除缓存项的接口，国内的UGC网站，因为严厉的内容检查制度和泛滥的垃圾广告，删帖子删图片特别频繁，某些网站可能高达40%（发100个贴，有40个帖子可能被删除或者修改)，所以对purge的效率有要求。
　　squid和varnish purge效率都达不到国内这种强度要求，nginx+memcache purge性能 要好很多
　　在当前的中国,遇到突发事件，你要不及时删除指定的链接，你的老板就可能会去拍下面这种相片

　　某门户网站曾经发生过，某个链接怎么也删不掉，一慌张把CDN所有缓存都删了重启，导致内网流量瞬间暴涨，各业务线的服务器全线报警，集体骂娘。
推荐CDN方案

• 中小型网站直接买服务就好，现在CDN已经进按需付费的云计算模式了，性价比是可以准确计算的
  
• 外地部署单点，推荐用squid
  
• 准备在公司内部实施私有云战略，推荐nginx+memcache
  

不建议使用varnish
　　以前的工作中，我力主把一个CDN集群从squid迁移到varnish，持续运行了2年，就是如上感受,严重不推荐.
标签: cdnnginxsquidvarnish
　　=================
　　http://blog.iyunv.com/21aspnet/article/details/7395920
　　对于坊间流传的:
1.varnish的性能比squid高10~20倍
2.squid 3.0的性能比2.6有提高
本次测试将会揭示结果,
是否varnish的架构真的能提升那么多的性能
是否squid的新版本在性能上有所提升
测试中将不对平台.软件.等等进行优化
由于优化水平的关系将极大的影响结果.
此次测试中的数据可以作为基准数据.
可以由其中个别软件的优化与非优化结果比例系数
自行计算得出比较结果.所以个别软件的优化或者系统优化后对整体的影响
可以由读者自行对特定软件进行,并使用此基准数据进行推算.
WEB站点的页面
我将淘宝的首页获取到本地
作为测试对象
测试页面下载
index_files
　　平台:
PROXY:
CentOS 5.1 最小化安装
浪潮NF190
Xeon 2.8
1G RAM
73G SCSI
Squid 2.6,Squid 3.0,Varnish 1.1.2
　　WEB:
CentOS 5.1 最小化安装
浪潮NF180
Xeon 2.8
1G RAM
73G SCSI
Nginx 0.6.31
　　CLIENT:
CentOS 5.1 最小化安装
浪潮NF260
Xeon 2.4
512M RAM
36G SCSI
http_load-12mar2006
　　SWITCH:
DLINK DES 1024R+
　　1.Squid 2.6
编译参数


./configure --prefix=/usr/local/squid26　　配置文件


visible_hostname test2.hiadmin.com
http_port 80 accel vhost vport
cache_peer 192.168.210.111 parent 80 0 no-query originserver name=test1
acl all src 0.0.0.0/0.0.0.0
http_access allow all
cache_log /var/log/squid26/cache.log　　2.Squid 3.0
编译参数


./configure --prefix=/usr/local/squid30　　配置文件


visible_hostname test2.hiadmin.com
http_port 80 accel vhost vport
cache_peer 192.168.210.111 parent 80 0 no-query originserver name=test1
acl all src 0.0.0.0/0.0.0.0
http_access allow all
cache_log /var/log/squid30/cache.log　　3.Varnish 1.1.2
编译参数


./configure --prefix=/usr/local/varnish　　配置文件


backend default {
   set backend.host = "192.168.210.111";
   set backend.port = "80";
}　　运行参数


varnishd -f /usr/local/varnish/default.vcl -a 0.0.0.0:80　　4.Nginx 0.6.31
编译参数


./configure --prefix=/usr/local/nginx　　配置文件


worker_processes 10;
events {
   worker_connections 1024;
}
http {
   include mime.types;
   default_type application/octet-stream;
   sendfile on;
   keepalive_timeout 65;
   server {
   listen 80;
   server_name localhost;
   location / {
   root html;
   index index.html index.htm;
   }
   error_page 500 502 503 504 /50x.html;
   location = /50x.html {
   root html;
   }
   }
}　　5.http_load
运行参数


./http_load -parallel 1000 -seconds 10 urls.txt
urls.txt
http://192.168.210.222/index.html　　6.squid 2.7
编译参数


./configure --prefix=/usr/local/squid27　　配置文件


visible_hostname test2.hiadmin.com
http_port 80 accel vhost vport
cache_peer 192.168.210.111 parent 80 0 no-query originserver name=test1
acl all src 0.0.0.0/0.0.0.0
http_access allow all
cache_log /var/log/squid27/cache.log　　测试结果

点图放大
图标中标注浅黄色的为客户端在抓取过程中只出现一次或几次的500
橙色的为出现500抓取错误的频率较多
红色的为几乎每次都会出现500抓取错误
值得注意的是squid 3.0
在500并发连接数时500出现的次数很多
但是在1000的时候反而抓取失败率下降了.
　　CPU和内存占用率

点图放大
varnish一直保持良好的CPU和内存使用率
但是到了1000并发数的时候
你会发现CPU使用率到了103%
没错.我并没有打错.在5次测试中,VARNISH的1000并发数测试其CPU占用率一直徘徊在101~103之间
可能是varnish的连接池写的不是特别好.当大于varnish处理量时,会使用更多的CPU资源去处理
squid 3.0似乎是个CPU和内存的占用大户
可能和版本比较新以及特性比较多有关(虽然这次什么特性都没用上)
squid 2.6保持了良好的姿态,稳定的CPU占用率和内存占用率.表明了为何市面上使用最多是它的原因.
　　更详细的内容可以下载此表格
varnish-vs-squid3
　　虽然varnish有着令人吃惊的CPU占用率(超过处理能力时也很令人吃惊)
但是其处理超大量的链接时内存和CPU使用率的暴涨并不令人满意
不过其表现出的在最大负荷时的fetchs/second
确实比squid 2.6要高出大约8%
实验表明.在需要更加稳定的生产环境中,varnish还不能替代老一代的squid 2.6
但是其对squid 3.0已经产生了很明显的挑战.
如果squid 3.0不能比他的上代产品提供更好的性能和稳定性的话
很有可能最佳反向代理的宝座会被varnish夺走
不论如何
这次测试的主题.varnish比squid有着10倍或者20倍的性能
被证实是不可能实现的.
虽然测试数据量充满100M带宽可能影响到测试的准确度.
但是更高的带宽所带来的同时连接数,很可能会撑爆varnish主机的CPU和内存.
　　结论
1.varnish在高负载下以CPU和内存为代价,比squid 2.6提高8%,但是绝非10倍~20倍.
2.squid 3.0的性能比2.6更低.而非更高.相反,3.0是最不稳定以及性能最差的.
3.squid 2.7的性能比2.6低,但是CPU和内存占用率控制的更好.
　　
　　======================================================
Squid 2.6 2.7 3.0 3.1 以及 varnish 2.1.5 性能对比测试
　　http://www.cnblogs.com/littlehb/archive/2012/02/21/2360787.html
　　

说明：

　　
　　使用压力测试软件siege，http_load对这几个代理软件进行测试，测试了不同大小的文件和各种并发数。
　　
　　squid的版本选择，考虑到实际使用的一些需求，并参考了其他的一些文章（
　　比如：http://www.php-oa.com/2009/12/02/cache%e8%bd%af%e4%bb%b6%e7%89%88%e6%9c%ac%e9%80%89%e6%8b%a9.html
　　），没有选择比较老的squid 2.5。
　　
　　每次测试前清除文件缓存并重启代理软件。
　　
　　这个测试仅作为数据参考，并不能完全模拟生产环境那么复杂的网络请求（请求数，各种大小的文件请求）。
　　
　　一、测试环境：
　　
　　硬件：Intel Xeon E5410 @ 2.33GHz * 2，16G内存，SATA 500G * 4（RAID 10）
　　
　　安装squid 2.7
　　
　　./configure -prefix=/opt/squid2.7 -enable-xmalloc-statistics --enable-async-io=320 --with-maxfd=65536 -enable-useragent-log -enable-referer-log -enable-epoll -disable-poll -enable-large-cache-files -disable-internal-dns -enable-linux-netfilter -enable-truncate -enable-x-accelerator-vary -enable-follow-x-forwarded-for -with-large-files -with-pthreads -enable-storeio="aufs,coss,diskd,ufs" -enable-kill-parent-hack -enable-gnuregex -enable-cache-digests -enable-delay-pools -enable-stacktraces -enable-default-err-language=Simplify_Chinese -enable-err-languages="Simplify_Chinese English" --enable-auth="basic" --enable-basic-auth-helpers="NCSA" --enable-snmp
　　
　　注意：
　　
　　1、不要使用-enable-dlmalloc这个编译参数，否则运行一段时间会报错 FATAL: xcalloc: Unable to allocate 1 blocks of 4112 bytes!
　　
　　参考：
　　
　　http://www.mail-archive.com/squid-users@squid-cache.org/msg48804.html
　　
　　http://www.mail-archive.com/squid-users@squid-cache.org/msg40839.html
　　
　　大致意思是dlmalloc是squid在某些系统本身malloc太烂的情况的代替方案，dlmalloc已经很老，且不支持2G以上内存（比较有意思的是之前使用的squid 3.0也用了这个参数，却正常运行，内存使用有配置超过10G的，可能3.0有特殊处理兼容了这种编译配置）。
　　
　　Squid 3的编译参数：
　　
　　www:/srv# /opt/squid3/sbin/squid -v
　　Squid Cache: Version 3.0.STABLE25
　　configure options: '--prefix=/opt/squid3' '--enable-dlmalloc' '--enable-gnuregex' '--enable-async-io=160' '--enable-removal-policies=heap,lru' '--enable-delay-pools' '--enable-storeio=ufs,aufs,null' '--disable-wccp' '--enable-kill-parent-hack' '--disable-select' '--enable-auth=basic' '--with-aio' '--disable-ident-lookup' '--with-filedescriptors=65536' '--enable-err-languages=Simplify_Chinese' '--enable-default-err-languages=Simplify_Chinese'
　　
　　3.1的编译参数基本和3.0一样。
　　
　　squid几个版本使用的基本是一样的squid.conf，性能相关的几个配置如下：
　　
　　cache_mem 4000 MB
　　maximum_object_size_in_memory 512 KB
　　
　　#cache_dir
　　cache_dir aufs /srv/squid_cache 20480 16 256
　　
　　maximum_object_size 4096 KB
　　
　　
　　Varnish:
　　
　　tar zxf varnish-2.1.5.tar.gz
　　cd varnish-2.1.5
　　./configure --prefix=/opt/varnish
　　
　　运行参数：
　　
　　/opt/varnish/sbin/varnishd -u www -g www -f /opt/varnish/etc/varnish/aipai.vcl -a 0.0.0.0:8080 -s file,/srv/varnish_cache/cache/varnish_cache.data,1G -w 1024,51200,10 -t 3600 -T 0.0.0.0:30000
　　
　　二、测试结果：
　　
　　每次测试60s
　　
　　测试命令：siege -b -c 100 -t 60s URL
　　
　　表中记录的数据是：Transaction rate，单位：请求/s
　　
　　典型测试结果：
　　
　　da01:~/siege-2.69# siege -b -c 500 -t 60s http://www.aipai.com:8080/about/map.html
　　** SIEGE 2.69
　　** Preparing 500 concurrent users for battle.
　　The server is now under siege...
　　Lifting the server siege...      done.
　　
　　Transactions:                 653211 hits  
　　Availability:                 100.00 %         
　　Elapsed time:                  59.35 secs
　　Data transferred:            1238.43 MB
　　Response time:                  0.05 secs               //平均相应时间
　　Transaction rate:           11006.08 trans/sec   //平均每秒处理速度，请求/s
　　Throughput:                    20.87 MB/sec          //网络吞吐量
　　Concurrency:                  498.86                         //最高并发数
　　Successful transactions:      653212                         //成功处理数
　　Failed transactions:               0                         //失败处理数
　　Longest transaction:            3.01                         //最长的请求处理时间
　　Shortest transaction:           0.00
　　
　　对于测试结果详细的说明，有兴趣的朋友请查阅siege的文档，比较关键的几个数据上面已经标注了。
　　
　　测试1：
　　
　　目标URL：http://www.aipai.com:8080/about/map.html，测试小文件请求，文件大小：6221 byte
　　

	并发 10	并发 100	并发 500	并发 1000
squid 2.6 STABLE23	8207	11211	11016	10451
squid 2.7 STABLE9	8261	11409	11006	10002
squid 3.0 STABLE25	8524	9762	8138	8768
squid 3.1.11	6421	6832	5990	5834
varnish 2.1.5	10875	10251	11459	11412

　　
　　PS：siege使用超过1000个并发会报错。
　　
　　测试2：
　　
　　目标URL：http://www.aipai.com:8080/c7/Pjg_KScqImgnaiYs.html，测试我们网站典型的播放页请求，文件大小：75356 byte
　　

	并发 10	并发 100	并发 500	并发 1000
squid 2.6 STABLE23	4554	6382	6625	6696（4 failed ）
squid 2.7 STABLE9	4164	6234	6565	6588
squid 3.0 STABLE25	4366	5315	5190	5153
squid 3.1.11	3697	4217	4357	4075
varnish 2.1.5	6618	6781	6775	5714

　　
　　
　　测试1，测试2总结：
　　
　　测试1，测试2都是对一个URL进行强压，主要测试MEM_HIT时候软件的处理能力。
　　
　　1、squid 2.6在squid组中基本是最快的，在测试2并发1000的时候开始不太稳定，有4个Connection timed out。
　　
　　2、squid 2.7的成绩和2.6在一个水平线，略逊一点。
　　
　　3、squid 从3.0开始用c++全部重写，目前看来与2.7/2.6性能差距还很明显，3.1从性能上来看比3.0还差（squid哥，不能为了功能损失太多的性能啊）。
　　
　　4、varnish在大多数测试上处于领先，有些项目差一些（varnish的测试结果不是很稳定，有一些摆幅）。varnish性能比squid强一些，不过远没有达到某些文章宣称的是squid的10倍。
　　
　　
　　测试3：
　　
　　进一步模拟生产环境，从实际运行的squid access log中截取了5万个url来测试。
　　
　　每次测试延长到2分钟。
　　

	并发 10	并发 100	并发 500	并发 1000
squid 2.6 STABLE23	2839	5485	6722	6604
squid 2.7 STABLE9	2981	5215	6789	6742
squid 3.0 STABLE25	2863	4294	4345	3859
squid 3.1.11	2682	3763	3402	3262
varnish 2.1.5	NA	NA	NA	NA

　　
　　4934
　　
　　注：varnish的测试有一点问题，siege会很快报出结果（并没有到设定的2分钟），查看varnish的log还在不断的有请求进来，这个测试中siege的结果不能使用。
　　
　　报错：
　　
　　** SIEGE 2.69
　　** Preparing 100 concurrent users for battle.
　　The server is now under siege...    done.
　　siege aborted due to excessive socket failure; you
　　can change the failure threshold in $HOME/.siegerc
　　Transactions:                 181336 hits
　　Availability:                  99.43 %
　　
　　测试3总结：
　　
　　1、由于varnish的成绩有问题，这里就只是squid各版本的比拼了。这个测试比之前的测试1，2更有意义一点，因为能更真实的模拟生产环境（url列表就是从生产环境中截取了一段）。
　　
　　2、在这个测试中squid 2.7表现的很出色，有3个环节的分数都比之前测试1，测试2中表现更好的squid 2.6高。

　　3、再验证测试的时候发现，这组测试结果变化较大。拿并发100时squid 2.7的数据来说，结果从3800到5600都有。分析原因可能是因为这里访问的是生产环境URL列表，需要去后端拿各种页面，有不少页面还需要请求数据库（后端和数据库这个时候都还在跑生产环境，并不是空闲的，当跑测试的时候数据库load明显升高），后端和数据库的繁忙程度会导致测试结果有一定偏差。
　　
　　4、有偏差也能看出一个大致趋势，和测试1，2的结论其实差不多：2.6/2.7的性能接近，3.0差一些，3.1最差。
　　
　　
　　增加的http_load测试：
　　
　　“测试3”对3万个url列表进行测试时，varnish的结果无效，考虑使用另外的压力测试工具来对比一下squid和varnish。
　　
　　这里使用http_load对“测试3”使用的url list进行测试（http_load 支持url 列表）。
　　

	并发 10	并发 100	并发 500	并发 1000
squid 2.6 STABLE23	4113（264 bad）	5612（415 bad）	5922（370 bad）	5768（354 bad）
squid 2.7 STABLE9	4253（277 bad）	5723（384 bad）	5600（341 bad）	5768（399 bad）
squid 3.0 STABLE25	4121（259 bad）	4786（350 bad）	3958（255 bad）	3868（228 bad）
squid 3.1.11	3405（206 bad）	3817（247 bad）	3384（183 bad）	3310（230 bad）
varnish 2.1.5	4985	6519（34 bad ）	6268（1191 bad）	6410（1065 bad）

　　
　　测试结果抽选：
　　
　　574373 fetches, 100 max parallel, 8.57065e+09 bytes, in 120 seconds
　　14921.7 mean bytes/connection
　　4786.44 fetches/sec, 7.14221e+07 bytes/sec
　　msecs/connect: 0.398121 mean, 3.682 max, 0.039 min
　　msecs/first-response: 9.73295 mean, 4198.23 max, 4.263 min
　　350 bad byte counts
　　HTTP response codes:
　　code 200 -- 542073
　　code 302 -- 26308
　　code 404 -- 5992
　　
　　注：
　　
　　1、varnish随着并发数的增多，有越来越多的 byte count wrong。
　　
　　http_load测试总结：
　　
　　1、从性能上来看，基本来之前的测试结论差不多：varnish > squid 2.6 > squid 2.7 > squid 3.0 > squid 3.1
　　
　　2、squid 2.6，2.7成绩很接近。
　　
　　3、需要留意的是随着并发数的增加，varnish出现的 bad byte counts比squid更多。
　　
　　
　　三、测试总结：
　　
　　
　　1、性能：varnish > squid 2.6 > squid 2.7 > squid 3.0 > squid 3.1
　　
　　2、squid 2.6和squid 2.7的成绩相差不大，大多数情况是2.6高一些，少数情况2.7高一些。
　　
　　3、squid 3.0，squid 3.1用c++重写之后目前性能上还比较尴尬。
　　
　　5、varnish的性能比squid好，不过远没有达到一些文章宣称的10倍，对varnish选择保持关注。原来使用的是squid，可以沿用不少的squid.conf配置，暂时先不换软件了，因为更换之后的配置熟悉以及正式上线的运行不确定性可能会有比较高的成本。
　　
　　4、最后选用squid 2.7。它有着和2.6相近的性能，更好的支持http 1.1，也有3.0支持的不少特性。
　　
　　http://www.iyunv.com/thread-10248-1-1.html
　　一：概括：
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来进行测试吧。
<ignore_js_op>
如图，-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万次@% 81.0万 pages/min	40.7万次@% 81.4万pages/min	40.8万次@% 81.7万pages/min	40.5万次@% 81.1万pages/min	40.6万99.9% 82.5万pages/min
Squid2.6-STABLE23-coss存储	44.2万次@% 86.1万 pages/min	45.2万次@% 87.1万 pages/min	44.3万次@% 89.3万 pages/min	44.5万次@% 87.3万 pages/min	44.1万99.9% 86.3万 pages/min
Varnish-3.0.2	70.1万次@% 140万pages/min	69.7万次@% 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万次@% 121.6万 pages/min	63.1万次@% 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万次@% 133.0万 pages/min	63.4万次@% 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:以上测试结果的数据受系统环境和应用程序参数的影响，因此不一定很准确，仅供参考。