Varnish 和 Squid比較到底強多少
使用壓力測試軟體siege,http_load對這幾個代理軟體進行測試,測試了不同大小的檔案和各種併發數。
squid的版本選擇,考慮到實際使用的一些需求,並參考了其他的一些文章(
),沒有選擇比較老的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
注意:
1、不要使用-enable-dlmalloc這個編譯引數,否則執行一段時間會報錯 FATAL: xcalloc: Unable to allocate 1 blocks of 4112 bytes!
參考:
大致意思是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
典型測試結果:
** 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:
併發 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:
併發 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支援的不少特性。