很多squid 優(yōu)化只限于在 squid
參數(shù)和系統(tǒng)參數(shù)上面的調(diào)整。但是這個(gè)實(shí)在只是細(xì)枝末節(jié)的事情，只要不是太弱智的配置導(dǎo)致無(wú)法緩存，squid的性能不會(huì)有太大差距，也就提高10%左右，只有實(shí)際的業(yè)務(wù)針對(duì)
squid 進(jìn)行一些調(diào)整，squid 才會(huì)真正爆發(fā)出他的能量，很多時(shí)候有 100%-200% 的提升。

本文基本是一些方向性的指導(dǎo)，并不涉及像具體配置文件的細(xì)節(jié)，因此本文里面的內(nèi)容大部分不能往配置文件里面 copy-paste。。

首先要明確一下，squid 能夠用來(lái)作什么。很多人沒(méi)有搞明白 squid 的工作原理，只是聽(tīng)說(shuō) squid
性能不錯(cuò)可以用來(lái)給網(wǎng)站提速，就直接在自己的 website 前面套了一個(gè) squid
，這基本沒(méi)有任何用處，即使你都是靜態(tài)頁(yè)面，后面apache上面沒(méi)有開(kāi)
mod_expires，一樣緩存不了，squid只能起到一個(gè)連接管理的用處。

一般說(shuō)來(lái)，網(wǎng)站用 squid 加速，目的有二

1: squid 本身具有緩存功能，可以將webserver輸出的內(nèi)容緩存起來(lái)，在緩存沒(méi)有過(guò)期之前來(lái)的訪問(wèn)，都直接用緩存里面的內(nèi)容，這樣可以有效減少
webserver 機(jī)器上面的請(qǐng)求數(shù)量。這是 squid 的主要功用。
2: 網(wǎng)絡(luò)慢的用戶(hù)會(huì)長(zhǎng)時(shí)間占用 webserver 的 TCP 連接，webserver
對(duì)每個(gè)連接占用的資源比較大，如果長(zhǎng)時(shí)間不能釋放出來(lái)服務(wù)其他請(qǐng)求，性能會(huì)有比較大的影響。前面放一個(gè) squid, webserver
就可以迅速處理完邏輯以后，把數(shù)據(jù)快速發(fā)送給 squid, 然后去處理別的邏輯，而 squid 每個(gè) TCP
連接占用的資源很少，不用擔(dān)心占用太多資源。這個(gè)用途也叫做連接管理，有一些網(wǎng)絡(luò)設(shè)備也可以做這個(gè)事情，價(jià)格都很貴。

下面針對(duì) squid 的兩種功用，來(lái)講述如何調(diào)整業(yè)務(wù)邏輯和 squid 參數(shù)

零：預(yù)操作

在搞 squid 之前，不管你用什么編譯配置，需要什么特殊選項(xiàng)，都請(qǐng) enable-snmp ，并配置好 mrtg
之類(lèi)，可以圖形化的顯示 squid 狀態(tài)，例如 Request Hit Ratio(RHR), Byte Hit Ratio(BHR),
等等，反饋是做一切事情的基礎(chǔ)，優(yōu)化也不例外。

?

一：緩存

A: 使用 Expires header 來(lái)控制緩存

squid在緩存webserver內(nèi)容的時(shí)候，需要后端webserver輸出一些控制信息告訴他頁(yè)面是不是可以被緩存，以及可以緩存多久。否則
squid 是不會(huì)自作主張給你緩存內(nèi)容的。一個(gè)頁(yè)面到底能不能緩存，只有開(kāi)發(fā)網(wǎng)站的人才知道，因此開(kāi)發(fā)人員有責(zé)任在動(dòng)態(tài)頁(yè)面里面輸出
Expires 和 Cache-Control header。簡(jiǎn)單舉一個(gè) php 的例子以說(shuō)明這兩個(gè) header
的值是什么含義，其中$expiretime 的單位是秒。

header("Expires: " . gmt_date_format(time()+$expiretime));
header("Cache-Control: max-age=" . "$expiretime");

對(duì)于靜態(tài)文件，有兩種方式來(lái)讓 squid 自動(dòng)給靜態(tài)文件緩存，一種是使用 apache 的 mod_expires
，可以針對(duì)路徑或者針對(duì)文件類(lèi)型/擴(kuò)展名來(lái)自動(dòng)輸出 cache 頭。詳細(xì)的請(qǐng)參考 mod_expires 的說(shuō)明 。另一種是用 squid 的
refresh_pattern 來(lái)指定。詳細(xì)的還是請(qǐng)參考 squid
的配置文件。一般來(lái)說(shuō)，如果后端不是配置很麻煩，建議還是在后端做，前端的配置修改大多數(shù)都是違背http協(xié)議的，如果出現(xiàn)問(wèn)題，也比較難排查。

?

B 根據(jù) squid 訪問(wèn)的模式，進(jìn)行業(yè)務(wù)拆分

　進(jìn)行了 Expires Header 的處理以后，squid
就真正可以起到加速的作用了，你可能也能感覺(jué)到，網(wǎng)站的訪問(wèn)速度明顯加快。但是不要滿(mǎn)足于這點(diǎn)成績(jī)，查看 squid 的 snmp 統(tǒng)計(jì)圖，通常
hit ratio 并不會(huì)太高，有 50% 就了不起了。這就是我們需要進(jìn)一步優(yōu)化的，我們的目標(biāo)是讓大部分 squid 都達(dá)到 9X%
的命中率。

為什么 squid 命中這么低呢，這大概有兩種原因。大多數(shù)的網(wǎng)站都是有一些頁(yè)面不能夠被緩存的，例如登錄頁(yè)面。這些頁(yè)面請(qǐng)求也從
squid 走，成為分母的一部分，直接就降低了命中率，我們首先可以做的事情是，把這些不能夠緩存的頁(yè)面請(qǐng)求，拆分到單獨(dú)一個(gè) squid
上面，或者訪問(wèn)量不大的話(huà)，干脆把 apache 暴露出來(lái)。這樣能夠緩存的那個(gè) squid 命中率馬上上升一截。

　有人可能會(huì)說(shuō)，把不能緩存的頁(yè)面分拆開(kāi)去，就光為了讓能緩存的那個(gè)數(shù)字好看，這不是掩耳盜鈴么？其實(shí)這么做是有意義的，首先就是去掉了不能緩存頁(yè)面的干擾，使得我們進(jìn)一步優(yōu)化
squid 的依據(jù)更加準(zhǔn)確。其次是不可緩存請(qǐng)求和可緩存請(qǐng)求之間的重要性通常是有差距的，分拆了以后，它們之間不容易互相搶占資源，不會(huì)因?yàn)橄螺d圖片的連接太多把
squid 占滿(mǎn)，影響更重要的登錄請(qǐng)求。第三就是可緩存內(nèi)容通常是圖片等頁(yè)面元素,　瀏覽器在 load
它們的時(shí)候，對(duì)每個(gè)站點(diǎn)的并發(fā)連接會(huì)有控制，如果分開(kāi)成不同的IP，可以多一些請(qǐng)求同時(shí)執(zhí)行。提高少許顯示速度。

其實(shí)觀察 sohu, sina 之類(lèi)的頁(yè)面，你會(huì)發(fā)現(xiàn)它們的頁(yè)面也是分拆的，可以看到頁(yè)面里面的圖片都是指向
images.sohu.com 之類(lèi)的地址，雖然它們可能和其他頁(yè)面一樣后臺(tái)都指向同一個(gè) apache。

　這樣做完，緩存命中率大概能上升到 70%-80% 了，運(yùn)氣好的時(shí)候完全可以上 90%。

另一種導(dǎo)致 squid
命中低的原因和這個(gè)比較類(lèi)似，同樣都是可緩存的內(nèi)容，有的可能是軟件下載站上面的大文件，有的是新聞?wù)军c(diǎn)上面的小圖片，如果同一個(gè) squid
對(duì)這樣差別巨大的文件加速的話(huà)，會(huì)嚴(yán)重干擾 squid 的緩存策略，兩者不能兼顧，要不就是大文件占據(jù)了 cache ，把小文件都擠出了
cache, 要不就是小文件特別多，大文件無(wú)法進(jìn)入 cache, 導(dǎo)致大文件經(jīng)常 miss
。這個(gè)比不能緩存的頁(yè)面還要惡心，因此即使在服務(wù)器資源有限的情況下，也要優(yōu)先拆分這兩類(lèi)型訪問(wèn)。一般來(lái)說(shuō)，文件大小分界線(xiàn)定在 1M
左右就可以了，如果是有軟件下載這樣特別大的文件，可以在 4M - 10M 左右再拆分一次。對(duì)于不同訪問(wèn)類(lèi)型的 squid,
其系統(tǒng)優(yōu)化參數(shù)也會(huì)有所不同，這個(gè)我們后面還會(huì)講到。

　只要悉心按照訪問(wèn)模式來(lái)拆分業(yè)務(wù)，大部分起緩存作用的 squid 都可以達(dá)到很高的命中率，至少都可以到達(dá) 9X%。

?

C 根據(jù)不同的需求，調(diào)整參數(shù)優(yōu)化緩存

完成 A 和 B 兩步優(yōu)化以后， squid 的命中率經(jīng)常可以達(dá)到 9x%, 可以說(shuō)我們已經(jīng)給 squid
創(chuàng)造了非常優(yōu)秀的外部環(huán)境，下面我們就要從 squid 本身入手，通過(guò)調(diào)整它的緩存參數(shù)和緩存策略，甚至系統(tǒng)的參數(shù)，來(lái)讓 squid
發(fā)揮出更好的性能。

在 B 步驟中，我們把 squid 劃分成了三種用途，緩存大文件，緩存小文件，不緩存文件，這其中最后一種用途情況下面 squid
不起到緩存效果，只用來(lái)做連接管理，因此我們把它放到后面的連接管理里面敘述，這里只討論和緩存相關(guān)的 squid 參數(shù)。
squid 有內(nèi)存緩存和磁盤(pán)緩存兩級(jí)緩存, 通常來(lái)說(shuō), 只要是專(zhuān)門(mén)給 squid 用的機(jī)器, 內(nèi)存緩存都建議開(kāi)得比較大,
大內(nèi)存緩存總是有好處的嘛, 但是注意不要使得系統(tǒng)開(kāi)始吃 swap ,像Linux這樣一開(kāi)始吃 swap 性能就下降比較嚴(yán)重的系統(tǒng)尤其要注意.
這個(gè)程度需要自己試驗(yàn)確定.
通常 1G 內(nèi)存的Linux機(jī)器用來(lái)跑 squid ,內(nèi)存緩存可以開(kāi)到 512M.

有些libc比較差的平臺(tái), 例如比較老的 freebsd 系統(tǒng), 其 malloc 函數(shù)的質(zhì)量不高,可能會(huì)造成比較多的內(nèi)存碎片,導(dǎo)致
squid 運(yùn)行一段時(shí)間以后分配不出來(lái)內(nèi)存掛掉. 這時(shí)候推薦在編譯時(shí)候使用 dlmalloc package. 即使如此, 仍然要再縮小
squid 的內(nèi)存緩存,以防不幸發(fā)生.

磁盤(pán)緩存的情況比較復(fù)雜, squid 有 ufs, aufs, coss, diskd, null 五種存儲(chǔ)后端, 其中 ufs,
aufs, diskd 都是在文件系統(tǒng)上面保存很多小文件, coss 是 squid
自己實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的文件系統(tǒng),可以使用一個(gè)大文件或者一個(gè)磁盤(pán)設(shè)備來(lái)存儲(chǔ). null 則是給不想要磁盤(pán)緩存的情況準(zhǔn)備的. coss
看起來(lái)好像比較拽, 但是以前試驗(yàn)并不足夠穩(wěn)定,因此并不推薦使用. 剩下的三種存儲(chǔ)方式,具體選擇哪種需要根據(jù)操作系統(tǒng)的特性來(lái)進(jìn)行.

ufs 是最傳統(tǒng)的存儲(chǔ)方式, 我們知道, squid 是一個(gè)單進(jìn)程的程序, 它使用 ufs 存儲(chǔ)后端時(shí), 直接在進(jìn)程里面讀寫(xiě)文件.
這是一種很簡(jiǎn)單的方式, 缺點(diǎn)是當(dāng)讀寫(xiě)磁盤(pán)被阻塞的時(shí)候, squid 不能夠處理請(qǐng)求, 會(huì)造成服務(wù)質(zhì)量波動(dòng)比較大. 因此出現(xiàn)了 aufs 和
diskd 兩種存儲(chǔ)后端, 原理都是 squid 主服務(wù)循環(huán)不負(fù)責(zé)讀寫(xiě)文件,
而是通過(guò)消息隊(duì)列或者tcp/pipe連接將數(shù)據(jù)傳送給其他的線(xiàn)程(aufs)/進(jìn)程(diskd), 然后其他線(xiàn)程/進(jìn)程進(jìn)行讀寫(xiě).
很顯然,這兩種存儲(chǔ)方式有一定的通信開(kāi)銷(xiāo), 因此不一定就比 ufs 好, 需要具體問(wèn)題具體分析

前面說(shuō)到, ufs/aufs/diskd都是在文件系統(tǒng)上面存儲(chǔ)很多小文件,因此文件系統(tǒng)本身的特性嚴(yán)重影響了squid緩存的性能,對(duì)于
Linux ,強(qiáng)烈推薦用 reiserfs 等適合處理小文件的文件系統(tǒng), bsd 則至少要打開(kāi) softupdate, 以及 dirhash
等一切對(duì)很多小文件有好處的選項(xiàng). 在比較新的系統(tǒng)上面, reiserfs 等文件系統(tǒng)的性能已經(jīng)足夠優(yōu)越, 通常 ufs 就已經(jīng)可以應(yīng)付需要.
對(duì)于一些老系統(tǒng),使用 aufs 或者 diskd 是比較好的選擇,如果系統(tǒng)的線(xiàn)程庫(kù)比較好(如Linux,Solaris),那么使用
aufs, 否則 diskd.
也有一些例外情況, 比如多 cpu 的 Linux 2.6 系統(tǒng), 線(xiàn)程庫(kù)很優(yōu)秀, 雖然 ufs 本身已經(jīng)比較快了,但是 squid
單進(jìn)程無(wú)法利用另外的 cpu , 不如使用 aufs , 讓另外的 cpu 也可以起到一些作用, aufs
在編譯的時(shí)候可以選擇使用幾個(gè)讀寫(xiě)線(xiàn)程. 這個(gè)個(gè)人覺(jué)得稍微超過(guò) cpu 個(gè)數(shù)就可以了.但是并沒(méi)有實(shí)際測(cè)試過(guò).

磁盤(pán)緩存開(kāi)多大? 這個(gè)問(wèn)題沒(méi)有固定答案. 需要經(jīng)過(guò)試驗(yàn)來(lái)確定, 一般來(lái)說(shuō)開(kāi)大一些沒(méi)有太大問(wèn)題. 只要你的硬盤(pán)足夠

(待續(xù))

最后致謝一下 windtear ，這位是 squid 之王, Lord of Squid,
業(yè)務(wù)分拆是從他那里學(xué)來(lái)的。致敬。(假如有人轉(zhuǎn)載請(qǐng)不要?jiǎng)h除這個(gè)，否則你也太沒(méi)良心了)

---------------以下是a總分析

A. 數(shù)據(jù)反饋

康神教導(dǎo)我們：反饋是做一切事情的基礎(chǔ)，優(yōu)化也不例外。那么具體看一些什么反饋數(shù)據(jù)呢？很遺憾，這個(gè)問(wèn)題沒(méi)有固定的答案，基本上需要具體問(wèn)題具體分析。具體來(lái)說(shuō)，用
cacti 之類(lèi)的看 squid snmp 數(shù)據(jù)是第一步。主要的數(shù)據(jù)有：

* BHR (Byte Hit Rate)/RHR (Request Hit Rate)，這兩個(gè)分別表示有多少數(shù)據(jù)量/請(qǐng)求數(shù)是被
squid hit cache 的。要特別注意的是，squid hit cache 并不等于 squid 不往主服務(wù)器發(fā)請(qǐng)求。具體情況在
squid 2.5/2.6 里面參看 isTcpHit() 函數(shù)。舉個(gè)例子，如果 RHR 顯示 90%，那么可能有 20% 的請(qǐng)求
squid 還是往主服務(wù)器發(fā)送了請(qǐng)求詢(xún)問(wèn)它過(guò)期的 cache
內(nèi)容是否有變化的，只不過(guò)主服務(wù)器的回應(yīng)是沒(méi)有變化。主服務(wù)器的判斷一般需要一次數(shù)據(jù)庫(kù)查詢(xún)或者文件系統(tǒng)的 stat
調(diào)用。高負(fù)荷服務(wù)器到最后如果瓶頸在主服務(wù)器磁盤(pán) I/O，這些貌似 HIT 的請(qǐng)求也會(huì)對(duì)主服務(wù)器造成一定量的沖擊。單純盲目追求高
BHR/RHR 是不可靠的。
* Service Time，這個(gè)是各類(lèi)請(qǐng)求的回應(yīng)時(shí)間，但是這個(gè)時(shí)間受到外部網(wǎng)絡(luò)速度的影響，所以也不一定代表真實(shí)的性能。另外，如果出現(xiàn)
Miss Service Time 比別的幾個(gè) Service Time
指標(biāo)高出很多，表示去主服務(wù)器的請(qǐng)求耗時(shí)比較長(zhǎng)，一般是代表瓶頸在主服務(wù)器那里，但這也不是絕對(duì)的。如果 squid 服務(wù)器磁盤(pán) I/O
性能跟不上或者 CPU 不夠強(qiáng)勁（squid 2 核心是可憐的單進(jìn)程），那么也可能是 squid 本身的調(diào)度出了問(wèn)題。
* Storage，在特定情況下可以估算 squid 每天緩存多少東西，在配置緩存大小等問(wèn)題的時(shí)候會(huì)有幫助。

總的來(lái)說(shuō)，squid snmp 數(shù)據(jù)是需要根據(jù)具體情況分析的，而且 squid snmp
的數(shù)據(jù)也不多，有時(shí)候往往需要配合別的監(jiān)控來(lái)綜合分析問(wèn)題，比方網(wǎng)絡(luò)出入流量，服務(wù)器的各類(lèi)性能分析，主服務(wù)器和 squid access
log。有一次我在某站 squid 調(diào)整了一個(gè)參數(shù)，結(jié)果那天 squid 的反應(yīng)奇好，BHR 更是上了前所未有的
98%。但是后來(lái)反復(fù)推敲發(fā)現(xiàn)這個(gè)參數(shù)并沒(méi)有作用，結(jié)合各類(lèi) log 分析發(fā)現(xiàn)是因?yàn)槟翘?frjj 貼了新照片，而且被盜鏈，導(dǎo)致巨大比例的
frjj 照片的請(qǐng)求被 squid 有效的緩存，squid 網(wǎng)絡(luò)出流量激增也支持這個(gè)結(jié)論。說(shuō)了半天，中心意思是高負(fù)荷服務(wù)器的 squid
優(yōu)化是一個(gè)長(zhǎng)期而艱巨的任務(wù)，某些參數(shù)的優(yōu)化需要幾天的數(shù)據(jù)才能得出有意義的結(jié)論，所以需要有足夠的耐心和針對(duì)實(shí)際情況的系統(tǒng)化的優(yōu)化步驟。

?

B. 緩存策略

康神教導(dǎo)我們：一般來(lái)說(shuō)，（緩存策略）如果后端不是配置很麻煩，建議還是在后端做，前端的配置修改大多數(shù)都是違背 http
協(xié)議的，如果出現(xiàn)問(wèn)題，也比較難排查。HTTP 緩存協(xié)議比較權(quán)威的可以參考 RF2616 第十三章，特別是 13.2 和 13.3
節(jié)。具體實(shí)現(xiàn)可以參考比方 Firefox 代碼 nsHttpResponseHead.cpp 的 ComputeCurrentAge() 和
ComputeFreshnessLifetime() 函數(shù)看看各類(lèi)情況的處理方式。mod_expires
的配置就需要深刻理解這些基本概念，否則可能反而會(huì)增加請(qǐng)求數(shù)。如果沒(méi)有特別的理由，靜態(tài)文件的過(guò)期時(shí)間一般是設(shè)置為 access time
加上一定量的時(shí)間。這個(gè)一定量的時(shí)間由具體情況決定。比如網(wǎng)站建設(shè)初期，各類(lèi)靜態(tài)文件可能需要比較短的過(guò)期時(shí)間以方便網(wǎng)站更新；而一旦美工敲定圖片，圖片的過(guò)期時(shí)間可以大膽的設(shè)置為幾個(gè)月。在配置完成以后如果沒(méi)有很大的把握也可以實(shí)際瀏覽一下分析請(qǐng)求序列看是否瀏覽器端和
squid 服務(wù)器都做到了有效的緩存，特別注意 cache 相關(guān)的請(qǐng)求和回復(fù)頭，包括 squid 提供的 X-Cache 頭。

另外，雖然違反 HTTP 協(xié)議的 squid 配置一般都不推薦，但是具體到細(xì)節(jié)上，這也不是絕對(duì)的原則。下面舉例說(shuō)說(shuō)必須違反 HTTP 協(xié)議的情況。

* 使用 javascript
做鏡像網(wǎng)站測(cè)速，一般實(shí)現(xiàn)方式是從各個(gè)鏡像站下載一個(gè)圖片看哪一個(gè)最快。最理想的情況是圖片在瀏覽器端不要緩存（以便下次準(zhǔn)確測(cè)速），但是這個(gè)請(qǐng)求又完全沒(méi)必要打到主服務(wù)器上。那么可以在
squid 里針對(duì)這個(gè)圖片 url 配置強(qiáng)制緩存 refresh_pattern reload-into-ims
ignore-reload。當(dāng)然這個(gè)例子很土鱉，只是舉個(gè)例子。
* reload_into_ims （這里說(shuō)的是 squid 的配置參數(shù)，不是 refresh_pattern 里面的
option）。這個(gè)參數(shù)雖然違反 HTTP 協(xié)議但是對(duì)大部分網(wǎng)站來(lái)說(shuō)是可以設(shè)置為 on 的，只要后端服務(wù)器對(duì)
If-Modified-Since 頭的判斷正確并且沒(méi)有潛在安全問(wèn)題即可。
* 瀏覽器 F5 刷新和 javascript 的 location.reload()
刷新可能會(huì)重新請(qǐng)求所有的網(wǎng)頁(yè)內(nèi)嵌元素并且可能帶 no-cache 請(qǐng)求頭，一般來(lái)說(shuō) reload_into_ims 設(shè)置成 on
已經(jīng)足夠保證對(duì)主服務(wù)器不造成沖擊，但是如果有必要可能還是需要在 squid 配置強(qiáng)制緩存。
* 針對(duì)土鱉客戶(hù)端的優(yōu)化。比如早期的 fterm 預(yù)覽圖片會(huì)發(fā)送 Pragma: no-cache 的請(qǐng)求頭，這勢(shì)必導(dǎo)致所有
fterm 預(yù)覽圖片的請(qǐng)求如數(shù)全部打在后端服務(wù)器上，所以解決方法是 squid 這里做手腳針對(duì)這類(lèi) url
配置強(qiáng)制緩存。一個(gè)細(xì)節(jié)問(wèn)題是如果不能緩存的圖片（比方有察看權(quán)限限制的）和能緩存的圖片的 url 結(jié)構(gòu)完全一樣，那么在 squid
強(qiáng)制緩存這類(lèi) url 的話(huà)又會(huì)有潛在的安全問(wèn)題，這里涉及到后面會(huì)講到的網(wǎng)站結(jié)構(gòu)優(yōu)化，針對(duì)這個(gè)問(wèn)題需要修改網(wǎng)站的代碼以明確區(qū)分這兩類(lèi)
url。還有另外一個(gè)例子是早期的 firefox 發(fā)送 XMLHttpRequest 請(qǐng)求也會(huì)發(fā)送 no-cache
的頭，后來(lái)的版本改了。當(dāng)年這一類(lèi) ajax 請(qǐng)求的 url 也是需要配置強(qiáng)制緩存的。
* 最后一個(gè)問(wèn)題是，如果在特殊情況下必須同時(shí)在后端服務(wù)器發(fā)送 Expires 頭，并且又在 squid 中配置這類(lèi) url 的
refresh_pattern，那么需要特別小心。比如，如果 squid 強(qiáng)制緩存時(shí)間比 mod_expires
配置的過(guò)期時(shí)間長(zhǎng)，那么可能造成 squid 發(fā)送已經(jīng)過(guò)期的內(nèi)容，導(dǎo)致瀏覽器本來(lái)可以有效緩存的內(nèi)容卻需要不斷的向服務(wù)器檢查更新。

最后，有些后端服務(wù)器沒(méi)辦法配置 mod_expires。這可能是因?yàn)闆](méi)有配置權(quán)限，也可能是因?yàn)楹蠖朔?wù)器軟件太土鱉，總之這樣的情況下就必須用
squid 配置 refresh_pattern 了。

?

C. 網(wǎng)站代碼及結(jié)構(gòu)優(yōu)化

康神教導(dǎo)我們：很多 squid 優(yōu)化（的文章）只限于在 squid
參數(shù)和系統(tǒng)參數(shù)上面的調(diào)整。但是這個(gè)實(shí)在只是細(xì)枝末節(jié)的事情，只要不是太弱智的配置導(dǎo)致無(wú)法緩存，squid
的性能不會(huì)有太大差距。網(wǎng)站優(yōu)化一般來(lái)說(shuō)也是屬于這種類(lèi)型的優(yōu)化，對(duì)于主服務(wù)器負(fù)荷瓶頸在磁盤(pán)
I/O，或者網(wǎng)絡(luò)瓶頸是大量大圖片文件的情況，優(yōu)化網(wǎng)站 html 結(jié)構(gòu)可能對(duì)性能提升沒(méi)有半點(diǎn)作用。不過(guò)即便如此，有一個(gè)為 squid
考慮的網(wǎng)站結(jié)構(gòu)，可以使得 squid 服務(wù)器的配置比較容易，也可以比較容易的實(shí)現(xiàn)多 squid
業(yè)務(wù)分拆，有的時(shí)候業(yè)務(wù)分拆并不是為了性能，而是為了更好的分析問(wèn)題以便進(jìn)一步優(yōu)化網(wǎng)站。下面簡(jiǎn)要說(shuō)說(shuō)有可能提高性能的網(wǎng)站代碼優(yōu)化。

* 減少頁(yè)面大小。這個(gè)問(wèn)題實(shí)在是到處都有好文章，我就不詳細(xì)說(shuō)了。常見(jiàn)技巧是分離 css/js
到單獨(dú)文件減少動(dòng)態(tài)主頁(yè)面大小同時(shí)保證靜態(tài)內(nèi)容有效緩存；頁(yè)面 layout 設(shè)計(jì)盡量使用 div+css；有大量冗余 html 元素的部分使用
javascript 來(lái)輸出。最后這個(gè)頁(yè)面 javascript 化可能需要考慮搜索引擎優(yōu)化 (SEO) 的問(wèn)題，總的來(lái)說(shuō)需要在減少流量和
SEO 之間尋找一個(gè)好的平衡點(diǎn)，這個(gè)只有做網(wǎng)站的人自己最清楚。
* 減少同一份數(shù)據(jù)的不同表現(xiàn)形式。大量使用 ajax 的站點(diǎn)有時(shí)候考慮 SEO 往往要重寫(xiě)一套給搜索引擎看的頁(yè)面，這勢(shì)必導(dǎo)致
squid 這里要存兩套頁(yè)面。但是如果功力足夠還是可以做到大部分頁(yè)面重用。舉例來(lái)說(shuō)，網(wǎng)站可能希望用戶(hù)讀文章不切換頁(yè)面而使用
XMLHttpRequest 載入，這個(gè)就可以在 <a href 寫(xiě)上文章內(nèi)容的頁(yè)面以便搜索引擎扒站同時(shí)也允許用戶(hù)在新窗口打開(kāi)這個(gè)文章，而
onclick 事件則觸發(fā) XMLHttpRequest
載入頁(yè)面并分析顯示內(nèi)容。只要代碼寫(xiě)的足夠漂亮，這里用一個(gè)文章頁(yè)面就可以實(shí)現(xiàn)所有的功能。
* 標(biāo)準(zhǔn)化 url。這個(gè)可以算前一條的補(bǔ)充。寫(xiě)網(wǎng)站如果不小心，可能同一個(gè)資源會(huì)有不同的 url。比方某篇文章，從主頁(yè)進(jìn)去的 url
是 article?bid=3&id=50，從搜索結(jié)果進(jìn)去卻是
article?id=50&bid=3。這樣兩個(gè)頁(yè)面，不但影響外部搜索引擎排名（自己和自己打架），更會(huì)影響 squid 效率，因?yàn)?br />squid 需要單獨(dú)存這兩類(lèi)頁(yè)面。
* 網(wǎng)站建設(shè)初期充分考慮到將來(lái)的 squid 優(yōu)化。舉例來(lái)說(shuō)，很多網(wǎng)站都在頁(yè)面帶用戶(hù)登錄信息顯示，這樣的頁(yè)面如果不使用
javascript 技巧就完全不可以在 squid 這里 cache。而實(shí)際上，如果這些動(dòng)態(tài)內(nèi)容可以在 javascript 里面通過(guò)
cookie 判斷出來(lái)，那么完全可以用 javascript 來(lái)寫(xiě)。這方面的細(xì)節(jié)工作做得越好，就有越多的頁(yè)面可以被 squid
安全的緩存。當(dāng)然這方面的優(yōu)化有時(shí)候也只有網(wǎng)站運(yùn)行起來(lái)才能發(fā)現(xiàn)，維護(hù)網(wǎng)站的時(shí)候多分析
log，多觀察，就可以發(fā)現(xiàn)這些細(xì)小的可以?xún)?yōu)化的地方，水滴石穿，大量小細(xì)節(jié)的優(yōu)化也可以帶來(lái)可觀的性能提升。

?

D. 一些雜問(wèn)題

* 同步 squid 和主服務(wù)器的時(shí)鐘。從原理上說(shuō)即使主服務(wù)器、squid
以及瀏覽器端的時(shí)鐘都不同步，應(yīng)該也不會(huì)造成緩存策略上的問(wèn)題，但是為了防止詭異問(wèn)題的發(fā)生，還是配置一下 squid 和主服務(wù)器的 ntpd
為好。ntp 是一個(gè)極輕量級(jí)的協(xié)議，現(xiàn)在網(wǎng)絡(luò)上 ntpd server 也遍地都是，保證服務(wù)器時(shí)鐘準(zhǔn)確到 1
秒之內(nèi)也可以保證別的一些程序的事務(wù)處理邏輯。
* 密切注意搜索引擎的動(dòng)向。有一些搜索引擎做的比較弱智，有的時(shí)候會(huì)突然發(fā)很多請(qǐng)求過(guò)來(lái)。搜索引擎扒站很容易扒到冷僻內(nèi)容，所以即使請(qǐng)求量只是普通瀏覽用戶(hù) 請(qǐng)求量的零頭，也可能會(huì)對(duì)主服務(wù)器造成沖擊。大部分搜索引擎還是比較守規(guī)矩的，甚至有些搜索引擎公司還可以與他們接觸配置扒站方案。不老實(shí)的搜索引擎可以 通過(guò)
squid 或者主服務(wù)器 log 找出來(lái)，特別不老實(shí)的可能 iptables 都能發(fā)現(xiàn)。解決方法比如可以針對(duì)搜索引擎 user agent
判斷，或者干脆 iptables 咔嚓掉。
* Cache replacement policy，對(duì)大論壇站點(diǎn)，雖然 lru 算法占用 cpu 較低，但是 service
time 可能會(huì)不如帶 dynamic aging 的算法穩(wěn)定。據(jù)觀察，lru
算法在運(yùn)行幾天之后的早晨如果突然碰到大量新請(qǐng)求，新請(qǐng)求會(huì)很難進(jìn)入
cache，或者進(jìn)入了也很快被踢出，導(dǎo)致非常容易形成惡性正反饋拖垮后臺(tái)服務(wù)器。但是假如每天清晨清 cache，并且保證磁盤(pán) cache
的量稍大于每天能存下來(lái)的量，那么 lru
算法應(yīng)該也不會(huì)比別的算法差（事實(shí)上什么算法都一樣了）。當(dāng)然這只是我的一家之言，一般來(lái)說(shuō)這個(gè)問(wèn)題還是需要根據(jù) squid
服務(wù)器性能和網(wǎng)站具體情況多次反復(fù)試驗(yàn)選擇最合適的算法。一般來(lái)說(shuō)小規(guī)模和超大規(guī)模的站點(diǎn)優(yōu)化這個(gè)參數(shù)可能不會(huì)有什么顯著的性能提升，所以不建議耗費(fèi)太多時(shí)間優(yōu)化這個(gè)。
* 一定時(shí)間清理 cache 并重啟 squid。這個(gè)有可能只是 squid 2.5
并且是高負(fù)荷破機(jī)器上需要考慮的一個(gè)方案。某站曾經(jīng)有段時(shí)間每天高峰期 Miss Service Time
都會(huì)飆升，但是主服務(wù)器卻沒(méi)有超負(fù)荷的現(xiàn)象，最后推測(cè)可能是 squid 自己調(diào)度的問(wèn)題。后來(lái)每三天清理 cache 并重啟 squid
似乎大大減少了這種現(xiàn)象。后據(jù)權(quán)威人士批復(fù)，這個(gè)可能是因?yàn)?squid cache replacement
算法過(guò)于古老，不適應(yīng)高速更新的大型論壇所致。
* 多域名宣傳的服務(wù)器。如果網(wǎng)站允許有多個(gè)域名但是所有的域名都指向同一個(gè)網(wǎng)站，那么要注意 squid
不要配置成多域名模式，否則它會(huì)把每個(gè)域名的 cache
都分開(kāi)處理，導(dǎo)致效率低下而且不能有效利用緩存存儲(chǔ)空間。題外話(huà)，單個(gè)網(wǎng)站宣傳多個(gè)域名也會(huì)影響搜索引擎排名等等，所以本質(zhì)上也是不推薦這么做的。
* maximum_object_size_in_memory，maximum_object_size
這兩個(gè)參數(shù)的配置也是具體問(wèn)題具體分析的。具體到某站上，常見(jiàn)的大文件就是附件了，由于附件最大允許大小是 5120 KB，所以
maximum_object_size 配置了 5123 KB 以保證即使最大的附件加上各 HTTP
頭也能有效的被緩存。最早這個(gè)參數(shù)是配置成 5120 KB 的，然后曾經(jīng)有一次發(fā)生 BHR 驟降的情況，后來(lái)分析發(fā)現(xiàn)是有人貼了 5120 KB
RAR 分卷壓縮的李宇春同學(xué)的視頻，而且恰好又有無(wú)數(shù)玉米下載，大量這類(lèi)請(qǐng)求因?yàn)槌菟远級(jí)旱搅酥鞣?wù)器上。另外
maximum_object_size_in_memory 的配置需要考慮網(wǎng)站具體情況和 squid 服務(wù)器的性能，這也需要實(shí)際試驗(yàn)出來(lái)。

最后廢話(huà)一句，現(xiàn)在硬件降價(jià)很快，給機(jī)群升級(jí)擴(kuò)容提升硬件性能往往比找個(gè)豬頭優(yōu)化 squid 配置更有效果，而且見(jiàn)效也快。所以在 squid
大配置沒(méi)有問(wèn)題的前提下，有錢(qián)的話(huà)應(yīng)該首選硬件優(yōu)化方案而不是軟件細(xì)節(jié)優(yōu)化。
為了您的安全，請(qǐng)只打開(kāi)來(lái)源可靠的網(wǎng)址
打開(kāi)網(wǎng)站??? 取消
來(lái)自: http://hi.baidu.com/youdianweidao/blog/item/14cd8266b88d042cab184cb0.html

?

總結(jié)

以上是生活随笔為你收集整理的squid 优化指南的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。