對于坊間流傳的:
1.varnish的性能比squid高10~20倍
2.squid 3.0的性能比2.6有提高
本次測試將會揭示結(jié)果,
是否varnish的架構(gòu)真的能提升那么多的性能
是否squid的新版本在性能上有所提升
測試中將不對平臺.軟件.等等進(jìn)行優(yōu)化
由于優(yōu)化水平的關(guān)系將極大的影響結(jié)果.
此次測試中的數(shù)據(jù)可以作為基準(zhǔn)數(shù)據(jù).
可以由其中個(gè)別軟件的優(yōu)化與非優(yōu)化結(jié)果比例系數(shù)
自行計(jì)算得出比較結(jié)果.所以個(gè)別軟件的優(yōu)化或者系統(tǒng)優(yōu)化后對整體的影響
可以由讀者自行對特定軟件進(jìn)行,并使用此基準(zhǔn)數(shù)據(jù)進(jìn)行推算.
WEB站點(diǎn)的頁面
我將淘寶的首頁獲取到本地
作為測試對象
測試頁面下載
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
編譯參數(shù)
配置文件
2.Squid 3.0
編譯參數(shù)
配置文件
3.Varnish 1.1.2
編譯參數(shù)
配置文件
運(yùn)行參數(shù)
4.Nginx 0.6.31
編譯參數(shù)
配置文件
5.http_load
運(yùn)行參數(shù)
6.squid 2.7
編譯參數(shù)
配置文件
更詳細(xì)的內(nèi)容可以下載此表格
varnish-vs-squid3
雖然varnish有著令人吃驚的CPU占用率(超過處理能力時(shí)也很令人吃驚)
但是其處理超大量的鏈接時(shí)內(nèi)存和CPU使用率的暴漲并不令人滿意
不過其表現(xiàn)出的在最大負(fù)荷時(shí)的fetchs/second
確實(shí)比squid 2.6要高出大約8%
實(shí)驗(yàn)表明.在需要更加穩(wěn)定的生產(chǎn)環(huán)境中,varnish還不能替代老一代的squid 2.6
但是其對squid 3.0已經(jīng)產(chǎn)生了很明顯的挑戰(zhàn).
如果squid 3.0不能比他的上代產(chǎn)品提供更好的性能和穩(wěn)定性的話
很有可能最佳反向代理的寶座會被varnish奪走
不論如何
這次測試的主題.varnish比squid有著10倍或者20倍的性能
被證實(shí)是不可能實(shí)現(xiàn)的.
雖然測試數(shù)據(jù)量充滿100M帶寬可能影響到測試的準(zhǔn)確度.
但是更高的帶寬所帶來的同時(shí)連接數(shù),很可能會撐爆varnish主機(jī)的CPU和內(nèi)存.
結(jié)論
1.varnish在高負(fù)載下以CPU和內(nèi)存為代價(jià),比squid 2.6提高8%,但是絕非10倍~20倍.
2.squid 3.0的性能比2.6更低.而非更高.相反,3.0是最不穩(wěn)定以及性能最差的.
3.squid 2.7的性能比2.6低,但是CPU和內(nèi)存占用率控制的更好.
======================================================
http://www.cnblogs.com/littlehb/archive/2012/02/21/2360787.html
使用壓力測試軟件siege，http_load對這幾個(gè)代理軟件進(jìn)行測試，測試了不同大小的文件和各種并發(fā)數(shù)。
squid的版本選擇，考慮到實(shí)際使用的一些需求，并參考了其他的一些文章（
比如：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。
每次測試前清除文件緩存并重啟代理軟件。
這個(gè)測試僅作為數(shù)據(jù)參考，并不能完全模擬生產(chǎn)環(huán)境那么復(fù)雜的網(wǎng)絡(luò)請求（請求數(shù)，各種大小的文件請求）。
一、測試環(huán)境：
硬件：Intel Xeon E5410 @ 2.33GHz * 2，16G內(nèi)存，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這個(gè)編譯參數(shù)，否則運(yùn)行一段時(shí)間會報(bào)錯(cuò) 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在某些系統(tǒng)本身malloc太爛的情況的代替方案，dlmalloc已經(jīng)很老，且不支持2G以上內(nèi)存（比較有意思的是之前使用的squid 3.0也用了這個(gè)參數(shù)，卻正常運(yùn)行，內(nèi)存使用有配置超過10G的，可能3.0有特殊處理兼容了這種編譯配置）。
Squid 3的編譯參數(shù)：
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的編譯參數(shù)基本和3.0一樣。
squid幾個(gè)版本使用的基本是一樣的squid.conf，性能相關(guān)的幾個(gè)配置如下：
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
運(yùn)行參數(shù)：
/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
二、測試結(jié)果：
每次測試60s
測試命令：siege -b -c 100 -t 60s URL
表中記錄的數(shù)據(jù)是：Transaction rate，單位：請求/s
典型測試結(jié)果：
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 //平均相應(yīng)時(shí)間
Transaction rate: 11006.08 trans/sec //平均每秒處理速度，請求/s
Throughput: 20.87 MB/sec //網(wǎng)絡(luò)吞吐量
Concurrency: 498.86 //最高并發(fā)數(shù)
Successful transactions: 653212 //成功處理數(shù)
Failed transactions: 0 //失敗處理數(shù)
Longest transaction: 3.01 //最長的請求處理時(shí)間
Shortest transaction: 0.00
對于測試結(jié)果詳細(xì)的說明，有興趣的朋友請查閱siege的文檔，比較關(guān)鍵的幾個(gè)數(shù)據(jù)上面已經(jīng)標(biāo)注了。
測試1：
目標(biāo)URL：http://www.aipai.com:8080/about/map.html，測試小文件請求，文件大?。?221 byte
| 并發(fā) 10 | 并發(fā) 100 | 并發(fā) 500 | 并發(fā) 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個(gè)并發(fā)會報(bào)錯(cuò)。
測試2：
目標(biāo)URL：http://www.aipai.com:8080/c7/Pjg_KScqImgnaiYs.html，測試我們網(wǎng)站典型的播放頁請求，文件大?。?5356 byte
| 并發(fā) 10 | 并發(fā) 100 | 并發(fā) 500 | 并發(fā) 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總結(jié)：
測試1，測試2都是對一個(gè)URL進(jìn)行強(qiáng)壓，主要測試MEM_HIT時(shí)候軟件的處理能力。
1、squid 2.6在squid組中基本是最快的，在測試2并發(fā)1000的時(shí)候開始不太穩(wěn)定，有4個(gè)Connection timed out。
2、squid 2.7的成績和2.6在一個(gè)水平線，略遜一點(diǎn)。
3、squid 從3.0開始用c++全部重寫，目前看來與2.7/2.6性能差距還很明顯，3.1從性能上來看比3.0還差（squid哥，不能為了功能損失太多的性能?。?/p>
4、varnish在大多數(shù)測試上處于領(lǐng)先，有些項(xiàng)目差一些（varnish的測試結(jié)果不是很穩(wěn)定，有一些擺幅）。varnish性能比squid強(qiáng)一些，不過遠(yuǎn)沒有達(dá)到某些文章宣稱的是squid的10倍。
測試3：
進(jìn)一步模擬生產(chǎn)環(huán)境，從實(shí)際運(yùn)行的squid access log中截取了5萬個(gè)url來測試。
每次測試延長到2分鐘。
| 并發(fā) 10 | 并發(fā) 100 | 并發(fā) 500 | 并發(fā) 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的測試有一點(diǎn)問題，siege會很快報(bào)出結(jié)果（并沒有到設(shè)定的2分鐘），查看varnish的log還在不斷的有請求進(jìn)來，這個(gè)測試中siege的結(jié)果不能使用。
報(bào)錯(cuò)：
** 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總結(jié)：
1、由于varnish的成績有問題，這里就只是squid各版本的比拼了。這個(gè)測試比之前的測試1，2更有意義一點(diǎn)，因?yàn)槟芨鎸?shí)的模擬生產(chǎn)環(huán)境（url列表就是從生產(chǎn)環(huán)境中截取了一段）。
2、在這個(gè)測試中squid 2.7表現(xiàn)的很出色，有3個(gè)環(huán)節(jié)的分?jǐn)?shù)都比之前測試1，測試2中表現(xiàn)更好的squid 2.6高。
3、再驗(yàn)證測試的時(shí)候發(fā)現(xiàn)，這組測試結(jié)果變化較大。拿并發(fā)100時(shí)squid 2.7的數(shù)據(jù)來說，結(jié)果從3800到5600都有。分析原因可能是因?yàn)檫@里訪問的是生產(chǎn)環(huán)境URL列表，需要去后端拿各種頁面，有不少頁面還需要請求數(shù)據(jù)庫（后端和數(shù)據(jù)庫這個(gè)時(shí)候都還在跑生產(chǎn)環(huán)境，并不是空閑的，當(dāng)跑測試的時(shí)候數(shù)據(jù)庫load明顯升高），后端和數(shù)據(jù)庫的繁忙程度會導(dǎo)致測試結(jié)果有一定偏差。
4、有偏差也能看出一個(gè)大致趨勢，和測試1，2的結(jié)論其實(shí)差不多：2.6/2.7的性能接近，3.0差一些，3.1最差。
增加的http_load測試：
“測試3”對3萬個(gè)url列表進(jìn)行測試時(shí)，varnish的結(jié)果無效，考慮使用另外的壓力測試工具來對比一下squid和varnish。
這里使用http_load對“測試3”使用的url list進(jìn)行測試（http_load 支持url 列表）。
| 并發(fā) 10 | 并發(fā) 100 | 并發(fā) 500 | 并發(fā) 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） |
測試結(jié)果抽選：
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隨著并發(fā)數(shù)的增多，有越來越多的 byte count wrong。
http_load測試總結(jié)：
1、從性能上來看，基本來之前的測試結(jié)論差不多：varnish > squid 2.6 > squid 2.7 > squid 3.0 > squid 3.1
2、squid 2.6，2.7成績很接近。
3、需要留意的是隨著并發(fā)數(shù)的增加，varnish出現(xiàn)的 bad byte counts比squid更多。
三、測試總結(jié)：
1、性能：varnish > squid 2.6 > squid 2.7 > squid 3.0 > squid 3.1
2、squid 2.6和squid 2.7的成績相差不大，大多數(shù)情況是2.6高一些，少數(shù)情況2.7高一些。
3、squid 3.0，squid 3.1用c++重寫之后目前性能上還比較尷尬。
5、varnish的性能比squid好，不過遠(yuǎn)沒有達(dá)到一些文章宣稱的10倍，對varnish選擇保持關(guān)注。原來使用的是squid，可以沿用不少的squid.conf配置，暫時(shí)先不換軟件了，因?yàn)楦鼡Q之后的配置熟悉以及正式上線的運(yùn)行不確定性可能會有比較高的成本。
4、最后選用squid 2.7。它有著和2.6相近的性能，更好的支持http 1.1，也有3.0支持的不少特性。
