感谢 xyy运营团队 总结
说明：
使用压力测试软件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
PS：siege使用超过1000个并发会报错。
测试2：
目标URL：http://www.aipai.com:8080/c7/Pjg_KScqImgnaiYs.html，测试我们网站典型的播放页请求，文件大小：75356 byte
测试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分钟。
注：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 列表）。
测试结果抽选：
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支持的不少特性。