简单的试试varnish和apache traffic server。跟squid进行一下对比。
介于varnish和ats都是出现不太久的东西（至少是开源流行不长），选择其最新开发版本测试，正巧都是2.15版。呵呵~
varnish配置文件，只修改了backend到具体某台nginx发布点上。其他都是反向代理缓存的标配。（可参考张宴博客http://blog.s135.com和varnish权威指南http://linuxguest.blog.51cto.com/195664/354889）
ats说明更少，从目前的资料看，修改了records.config中的监听，cache.config遵循源站未改，remap.config添加了map一条，绑定域名到同一台nginx上。
注：varnish和ats都没有修改缓存路径，即分别为var/varnish/varnish.cache和var/trafficserver，都是磁盘。
然后从线上某台squid2.7上收集www.domain.com下的html页面url一共164条，存成urllist。
使用http_load进行测试。第一遍，先用http_load -r 100 -s 10完成cache的加载；第二遍改用-r 1000 -s 60进行测试。
1、先是varnish
开另一个窗口看netstat，发现在第一次加载的时候，varnish启动了相当多的链接到后端nginx请求数据！第二遍时，-r1000一直在刷wrong，修改成-r900就没有问题。最后的报告显示fetch/sec还略大于指定的900达到990，建连时间平均1.3ms，响应时间1.8ms。
2、然后ats
-r1000也报wrong，于是同样使用-r900，fetch/sec和和建连时间与varnish相近，响应时间2.1ms。
从trafficserver_shell的show:proxy_stats和show:cache_stats命令结果来看，缓存命中率98%，磁盘IO几乎没有。可见其实都在内存中返回了。
3、最后squid2.7.9
-r900时，fetch/sec只有880，响应时间1.9ms；提高到-r1000时，没有wrong报错，fetch/sec下降到850，响应时间2.3ms；另一个窗口的netstat命令直接卡住……
squid按照公司默认做法，缓存目录建在了tmpfs上。从squidclient来看，98%的命中率中只有三分之一是直接通过cache_mem返回的，另三分之二是通过cache_dir的tmpfs返回。
另：最后du -sh查看三者的缓存目录大小，赫然发现squid的是19M，ats是39M，varnish是41M。这个差别也是比较怪异的，值得后续研究……
从这个简单测试结果看，squid的稳定性依然没的说：对于大多数情况来说，是乐于见到这种宁愿响应慢点点也要保证响应正确的情况的；varnish在大批量回源时对后端服务器的冲击，显然比较让人担心；ats和varnish具有同样高效的响应速度（和高压下的错误……），而且其详细到甚至稍显繁琐的那堆config文件的配置格式，相比varnish来说，更加贴近运维人员（也就是说看起来不像编程语言）~~
