client_conn 9908723 94.05 Client connections acceptedclient_drop 0 0.00 Connection dropped, no sess/wrkclient_req 16433490 155.99 Client requests receivedcache_hit 8751732 83.07 Cache hitscache_hitpass 42592 0.40 Cache hits for passcache_miss 7573389 71.89 Cache missesbackend_conn 3889845 36.92 Backend conn. successbackend_unhealthy 220 0.00 Backend conn. not attemptedbackend_busy 0 0.00 Backend conn. too manybackend_fail 4536 0.04 Backend conn. failuresbackend_reuse 3780212 35.88 Backend conn. reusesbackend_toolate 3866687 36.70 Backend conn. was closedbackend_recycle 7646677 72.58 Backend conn. recyclesbackend_unused 0 0.00 Backend conn. unusedfetch_head 57 0.00 Fetch headfetch_length 155097 1.47 Fetch with Lengthfetch_chunked 7508522 71.27 Fetch chunkedfetch_eof 0 0.00 Fetch EOFfetch_bad 0 0.00 Fetch had bad headersfetch_close 3982 0.04 Fetch wanted closefetch_oldhttp 0 0.00 Fetch pre HTTP/1.1 closedfetch_zero 0 0.00 Fetch zero lenfetch_failed 0 0.00 Fetch failedn_sess_mem 1033 . N struct sess_memn_sess 633 . N struct sessn_object 1016443 . N struct objectn_vampireobject 0 . N unresurrected objectsn_objectcore 1017564 . N struct objectcoren_objecthead 982903 . N struct objectheadn_smf 2647421 . N struct smfn_smf_frag 622470 . N small free smfn_smf_large 3 . N large free smfn_vbe_conn 12 . N struct vbe_connn_wrk 8000 . N worker threadsn_wrk_create 8000 0.08 N worker threads createdn_wrk_failed 0 0.00 N worker threads not createdn_wrk_max 11021 0.10 N worker threads limitedn_wrk_queue 0 0.00 N queued work requestsn_wrk_overflow 2441 0.02 N overflowed work requestsn_wrk_drop 0 0.00 N dropped work requestsn_backend 4 . N backendsn_expired 6344546 . N expired objectsn_lru_nuked 183957 . N LRU nuked objectsn_lru_saved 0 . N LRU saved objectsn_lru_moved 3692170 . N LRU moved objectsn_deathrow 0 . N objects on deathrowlosthdr 84 0.00 HTTP header overflowsn_objsendfile 0 0.00 Objects sent with sendfilen_objwrite 15466812 146.81 Objects sent with writen_objoverflow 0 0.00 Objects overflowing workspaces_sess 9906155 94.03 Total Sessionss_req 16433490 155.99 Total Requestss_pipe 37 0.00 Total pipes_pass 108252 1.03 Total passs_fetch 7667658 72.78 Total fetchs_hdrbytes 7187255662 68221.35 Total header bytess_bodybytes 111592032839 1059230.32 Total body bytessess_closed 1905544 18.09 Session Closedsess_pipeline 0 0.00 Session Pipelinesess_readahead 0 0.00 Session Read Aheadsess_linger 15277717 145.02 Session Lingersess_herd 13547370 128.59 Session herdshm_records 1028855796 9765.89 SHM recordsshm_writes 77957008 739.97 SHM writesshm_flushes 131005 1.24 SHM flushes due to overflowshm_cont 144281 1.37 SHM MTX contentionshm_cycles 427 0.00 SHM cycles through buffersm_nreq 15306717 145.29 allocator requestssm_nobj 2024948 . outstanding allocationssm_balloc 13595295744 . bytes allocatedsm_bfree 40091795456 . bytes freesma_nreq 0 0.00 SMA allocator requestssma_nobj 0 . SMA outstanding allocationssma_nbytes 0 . SMA outstanding bytessma_balloc 0 . SMA bytes allocatedsma_bfree 0 . SMA bytes freesms_nreq 14062 0.13 SMS allocator requestssms_nobj 0 . SMS outstanding allocationssms_nbytes 487 . SMS outstanding bytessms_balloc 6844837 . SMS bytes allocatedsms_bfree 6846298 . SMS bytes freedbackend_req 7668789 72.79 Backend requests maden_vcl 1 0.00 N vcl totaln_vcl_avail 1 0.00 N vcl availablen_vcl_discard 0 0.00 N vcl discardedn_purge 740577 . N total active purgesn_purge_add 905392 8.59 N new purges addedn_purge_retire 164815 1.56 N old purges deletedn_purge_obj_test 13397373 127.17 N objects testedn_purge_re_test 131875330367 1251759.15 N regexps tested againstn_purge_dups 240655 2.28 N duplicate purges removedhcb_nolock 0 0.00 HCB Lookups without lockhcb_lock 0 0.00 HCB Lookups with lockhcb_insert 0 0.00 HCB Insertsesi_parse 0 0.00 Objects ESI parsed (unlock)esi_errors 0 0.00 ESI parse errors (unlock)accept_fail 2553 0.02 Accept failuresclient_drop_late 0 0.00 Connection dropped lateuptime 105352 1.00 Client uptime
看起來(lái)很強大，的確，它幫我們獲得了很多重要的信息，包括了三個(gè)重要的統計項：
N struct object
當前被cache的條目
Client requests received
代表到目前為止，瀏覽器向反向代理服務(wù)器發(fā)送的HTTP請求累積次數，由于可能使用長(cháng)連接，所以它可能會(huì )大于上邊的Client connections accepted。
Cache hits
代表在這些請求中，反向代理服務(wù)器在緩存區中查找并且命中緩存的次數。
Cache misses
代表在這些請求中，反向代理服務(wù)器在緩存區中查找但是沒(méi)有命中緩存的次數。
N expired objects
代表過(guò)期的緩存內容個(gè)數
N LRU nuked objects
由于cache空間滿(mǎn)而不得不扔掉的cache條目，如果這個(gè)數字是0，就沒(méi)必要增加cache的大小了。
N LRU moved objects
代表被淘汰的緩存內容個(gè)數
Total header bytes
代表緩存區中所有緩存內容的HTTP頭信息長(cháng)度
Total body bytes
代表緩存區中所有緩存內容的正文長(cháng)度
通過(guò)以上這些統計項，我們還可以知道更多，比如Cache hits和Cache misses的總和代表了反向代理服務(wù)器在緩存區中查找內容的總次數；而用Client requests received減去這個(gè)總次數，便大概等于沒(méi)有查找緩存的請求數；Total body bytes和Total body bytes的總和則代表了緩存區當前的空間使用量。
了解了這些后，我們回頭看前邊的三個(gè)問(wèn)題，都很容易分析和解決。
對于緩存區空間大小的問(wèn)題，我們可以通過(guò)監視它的使用量以及緩存淘汰個(gè)數，在必要的時(shí)候分配更多的緩存區空間，但是這可能需要重新啟動(dòng)反向代理服務(wù)器。當然，我們應該首先根據站點(diǎn)的規模，來(lái)估算出大概的緩存區空間，并且分配出大約為它5倍以上的緩存區空間，以適應一段時(shí)期內的內容數量增長(cháng)。
其次，是緩存有效期取值的問(wèn)題，但這本身不是一個(gè)問(wèn)題，它取決于后端Web服務(wù)器的承受能力，以及你對站點(diǎn)內容實(shí)時(shí)性的要求，我們在前邊介紹動(dòng)態(tài)內容緩存的章節中曾經(jīng)探討過(guò)緩存有效期的取值，實(shí)質(zhì)上是一個(gè)尋找“過(guò)”與“不及”之間平衡的長(cháng)期過(guò)程，但在動(dòng)態(tài)程序實(shí)現的內容緩存機制中，我們還可以通過(guò)主動(dòng)刪除緩存的方法來(lái)實(shí)現緩存到期之前的更新，而基于HTTP協(xié)議的反向代理緩存機制則不容易做到這一點(diǎn)，后端的動(dòng)態(tài)程序無(wú)法主動(dòng)刪除某個(gè)緩存內容，除非我們清空反向代理服務(wù)器上的緩存區。
在尋找平衡的過(guò)程中，有時(shí)候實(shí)時(shí)性需求可能要向緩存有效期適當讓步，當我們的站點(diǎn)面臨較大的壓力時(shí)，我們不得不暫時(shí)以犧牲實(shí)時(shí)性作為代價(jià)，適當的延長(cháng)緩存有效期，直到我們有了成熟的性能擴展方案。
在初步評估緩存有效期的時(shí)候，我們可以通過(guò)一些量化的計算來(lái)得出理論數值，舉個(gè)例子，假如我們的站點(diǎn)有60000個(gè)動(dòng)態(tài)內容處于頻繁訪(fǎng)問(wèn)的狀態(tài)，我們通過(guò)Cache-Control將它們在反向代理服務(wù)器上的緩存有效期都設置為60秒，這樣一樣來(lái)，后端服務(wù)器將必須承受最多每秒處理1000個(gè)動(dòng)態(tài)內容的工作量，如果這些動(dòng)態(tài)內容都進(jìn)行完整的計算，比如訪(fǎng)問(wèn)數據庫，那么顯然后端服務(wù)器是無(wú)法承受的，這時(shí)候我們可以將緩存有效期延長(cháng)到300秒，即5分鐘，這使得后端服務(wù)器只需要每秒處理200個(gè)動(dòng)態(tài)內容，大大減少了工作量。
那么，如果從緩存命中率的角度來(lái)分析緩存有效期取值的時(shí)候，有一點(diǎn)需要明白，當我們看到緩存的命中率非常低時(shí)，有時(shí)并不代表我們需要馬上延長(cháng)緩存有效期，這時(shí)候還要觀(guān)察當前的站點(diǎn)實(shí)際吞吐率，舉個(gè)極端的例子，假如你發(fā)現你的站點(diǎn)1個(gè)小時(shí)內只有1次訪(fǎng)問(wèn)，而緩存有效期為半個(gè)小時(shí)，那緩存命中率必然會(huì )非常低，但即便是每次緩存都不命中，也不會(huì )對后端帶來(lái)什么壓力，實(shí)際上如果你的站點(diǎn)只有一臺Web服務(wù)器，并且站點(diǎn)的實(shí)際吞吐率遠遠低于它的處理能力時(shí)，完全沒(méi)有必要使用反向代理服務(wù)器。
最后關(guān)于內容沒(méi)有被緩存的問(wèn)題，我們也可以在Varnish的狀態(tài)監視中找到線(xiàn)索，比如有一個(gè)用Varnish加速第三方應用wordpress的例子，得到的Varnish狀態(tài)如下：
4+10:37:44my.server.comHitrate ratio: 1 1 1Hitrate avg: 0.0364 0.0364 0.03642324 0.00 0.01 Client connections accepted6191 0.00 0.02 Client requests received12 0.00 0.00 Cache hits7 0.00 0.00 Cache hits for pass318 0.00 0.00 Cache misses6179 0.00 0.02 Backend connections success0 0.00 0.00 Backend connections notattempted0 0.00 0.00 Backend connections too many0 0.00 0.00 Backend connections failures4057 0.00 0.01 Backend connections reuses6151 0.00 0.02 Backend connections recycles...
我們看到，Varnish一共處理了來(lái)自瀏覽器的6191個(gè)請求，其中命中緩存的有12個(gè)，真是太少了，而沒(méi)有命中緩存的有318個(gè)，奇怪，剩下的那么多請求根本就沒(méi)有去緩存區檢查，也就是說(shuō)，Varnish認為那些內容不能被緩存。不能被緩存總是有原因的，你需要根據反向代理緩存的規則，來(lái)進(jìn)一步的檢查。而我們這個(gè)例子中，都是cookies惹得禍，因為在wordpress中由于我們會(huì )安裝一些各種各樣的插件，有些插件會(huì )使得wordpress的每個(gè)頁(yè)面都帶有寫(xiě)入cookies的set-cookie標記，而我們前邊在vcl_fetch函數中禁止了這類(lèi)內容的緩存，問(wèn)題就在這里了，我們希望將這些多余的cookie關(guān)閉掉，但是，wordpress自身的登錄和管理頁(yè)面是需要cookies才可以正常工作的，所以我們還需要讓反向代理不緩存這些頁(yè)面，我們使用以下VCL配置：
sub vcl_recv{if (!(req.url ~ "wp-(login|admin)")){unset req.http.cookie;}}sub vcl_fetch{if (!(req.url ~ "wp-(login|admin)")){unset obj.http.set-cookie;}}可以看到，除了wordpress自身的登錄和管理頁(yè)面以外，我們將其它內容的HTTP頭信息中有關(guān)cookie的標記全部都清除掉，這使得Varnish可以將大部分內容緩存起來(lái)，提高緩存命中率，同時(shí)不影響我們登錄和管理wordpress。
這個(gè)例子給了我們一些啟示，對于我們自己的站點(diǎn)，如果從長(cháng)遠考慮，那么在規劃的時(shí)候就要費點(diǎn)心思，我們可以根據內容是否可以緩存在反向代理服務(wù)器上，將它們置于不同的主機，這樣便可以在必要的時(shí)候將可以緩存的內容快速與反向代理服務(wù)器對接，獲得較好的加速效果。
聯(lián)系客服
