说明：
并发 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://hi.baidu.com/aboutstudy/blog/item/9abe42fbea74b4284f4aead0.html