內容摘要：
對於一個日訪問量達到百萬級的網站來說，速度很快就成爲一個瓶頸。除了優化內容發佈系統的應用本身外，如果能把不需要實時更新的動態頁面的輸出結果轉化成靜態網頁來發布，速度上的提升效果將是顯著的，因爲一個動態頁面的速度往往會比靜態頁面慢2－10倍，而靜態網頁的內容如果能被緩存在內存裏，訪問速度甚至會比原有動態網頁有2－3個數量級的提高。
- 動態緩存和靜態緩存的比較
- 基於反向代理加速的站點規劃
- 基於apache mod_proxy的反向代理加速實現
- 基於squid的反向代理加速實現
- 面向緩存的頁面設計
- 應用的緩存兼容性設計：
HTTP_HOST/SERVER_NAME和REMOTE_ADDR/REMOTE_HOST需要用 HTTP_X_FORWARDED_HOST/HTTP_X_FORWARDED_SERVER代替
靜態緩存和動態緩存的比較
靜態頁面的緩存可能有2種形式：其實主要區別就是CMS是否自己負責關聯內容的緩存更新管理。
- 靜態緩存：是在新內容發佈的同時就立刻生成相應內容的靜態頁面，比如：2003年3月22日，管理員通過後臺內容管理界面錄入一篇文章後，就立刻生成http://www.chedong.com/tech/2003/03/22/001.html這個靜態頁面，並同步更新相關索引頁上的鏈接。
- 動態緩存：是在新內容發佈以後，並不預先生成相應的靜態頁面，直到對相應內容發出請求時，如果前臺緩存服務器找不到相應緩存，就向後臺內容管理服務器發出請求，後臺系統會生成相應內容的靜態頁面，用戶第一次訪問頁面時可能會慢一點，但是以後就是直接訪問緩存了。
如果去ZDNet等國外網站會發現他們使用的基於Vignette內容管理系統都有這樣的頁面名稱：0,22342566,300458.html。其實這裏的0,22342566,300458就是用逗號分割開的多個參數：
第一次訪問找不到頁面後，相當於會在服務器端產生一個doc_type= 0&doc_id=22342566&doc_template=300458的查詢，
而查詢結果會生成的緩存的靜態頁面： 0,22342566,300458.html
靜態緩存的缺點：
- 複雜的觸發更新機制：這兩種機制在內容管理系統比較簡單的時候都是非常適用的。但對於一個關係比較複雜的網站來說，頁面之間的邏輯引用關係就成爲一個非常非常複雜的問題。最典型的例子就是一條新聞要同時出現在新聞首頁和相關的3個新聞專題中，在靜態緩存模式中，每發一篇新文章，除了這篇新聞內容本身的頁面外，還需要系統通過觸發器生成多個新的相關靜態頁面，這些相關邏輯的觸發也往往就會成爲內容管理系統中最複雜的部分之一。
- 舊內容的批量更新： 通過靜態緩存發佈的內容，對於以前生成的靜態頁面的內容很難修改，這樣用戶訪問舊頁面時，新的模板根本無法生效。
在動態緩存模式中，每個動態頁面只需要關心，而相關的其他頁面能自動更新，從而大大減少了設計相關頁面更新觸發器的需要。
以前做小型應用的時候也用過類似方式：應用首次訪問以後將數據庫的查詢結果在本地存成一個文件，下次請求時先檢查本地緩存目錄中是否有緩存文件，從而減少對後臺數據庫的訪問。雖然這樣做也能承載比較大的負載，但這樣的內容管理和緩存管理一體的系統是很難分離的，而且數據完整性也不是很好保存，內容更新時，應用需要把相應內容的的緩存文件刪除。但是這樣的設計在緩存文件很多的時候往往還需要將緩存目錄做一定的分佈，否則一個目錄下的文件節點超過3000，rm *都會出錯。
這時候，系統需要再次分工，把複雜的內容管理系統分解成：內容輸入和緩存這2個相對簡單的系統實現。
- 後臺：內容管理系統，專心的將內容發佈做好，比如：複雜的工作流管理，複雜的模板規則等……
- 前臺：頁面的緩存管理則可以使用緩存系統實現
______________________ ___________________
|Squid Software cache| |F5 Hardware cache|
---------------------- -------------------
/ /
/ ________________ /
|ASP |JSP |PHP |
Content Manage System
----------------
所以分工後：內容管理和緩存管理2者，無論哪一方面可選的餘地都是非常大的：軟件（比如前臺80端口使用SQUID對後臺8080的內容發佈管理系統進行緩存），緩存硬件，甚至交給akamai這樣的專業服務商。
面向緩存的站點規劃
一個利用SQUID對多個站點進行做WEB加速http acceleration方案：原先一個站點的規劃可能是這樣的：
200.200.200.207 www.chedong.com
200.200.200.208 news.chedong.com
200.200.200.209 bbs.chedong.com
200.200.200.205 images.chedong.com
面向緩存服務器的設計中：所有站點都通過外部DNS指向到同一個IP：200.200.200.200/201這2臺緩存服務器上（使用2臺是爲了冗餘備份）
_____________________ ________工作原理：
www.chedong.com 請求 / | cache box | | | / 192.168.0.4 www.chedong.com
news.chedong.com 請求 -| 200.200.200.200/201 |-|firewall| - 192.168.0.4 news.chedong.com
bbs.chedong.com 請求 / | /etc/hosts | | box | / 192.168.0.3 bbs.chedong.com
--------------------- --------
外部請求過來時，設置緩存根據配置文件進行轉向解析。這樣，服務器請求就可以轉發到我們指定的內部地址上。
在處理多虛擬主機轉向方面：mod_proxy比squid要簡單一些：可以把不同服務轉向後後臺多個IP的不同端口上。
而squid只能通過禁用DNS解析，然後根據本地的/etc/hosts文件根據請求的域名進行地址轉發，後臺多個服務器必須使用相同的端口。
使用反向代理加速，我們不僅可以得到性能上的提升，而且還能獲得額外的安全性和配置的靈活度：
- 配置靈活性提高：可以自己在內部服務器上控制後臺服務器的DNS解析，當需要在服務器之間做遷移調整時，就不用大量修改外部DNS配置了，只需要修改內部DNS實現服務的調整。
- 數據安全性增加：所有後臺服務器可以很方便的被保護在防火牆內。
- 後臺應用設計複雜程度降低：原先爲了效率常常需要建立專門的圖片服務器images.chedong.com和負載比較高的應用服務器 bbs.chedong.com分離，在反向代理加速模式中，所有前臺請求都通過緩存服務器：實際上就都是靜態頁面，這樣，應用設計時就不用考慮圖片和應用本身分離了，也大大降低了後臺內容發佈系統設計的複雜程度，由於數據和應用都存放在一起，也方便了文件系統的維護和管理。
基於Apache mod_proxy的反向代理緩存加速實現
Apache包含了mod_proxy模塊，可以用來實現代理服務器，針對後臺服務器的反向加速安裝apache 1.3.x 編譯時：
--enable-shared=max --enable-module=most
注：Apache 2.x中mod_proxy已經被分離成mod_proxy和mod_cache：同時mod_cache有基於文件和基於內存的不同實現
創建/var/www/proxy，設置apache服務所用戶可寫
mod_proxy配置樣例：反相代理緩存＋緩存
架設前臺的www.example.com反向代理後臺的www.backend.com的8080端口服務。
修改：httpd.conf
<VirtualHost *>
ServerName www.example.com
ServerAdmin [email protected]
# reverse proxy setting
ProxyPass / http://www.backend.com:8080/
ProxyPassReverse / http://www.backend.com:8080/
# cache dir root
CacheRoot "/var/www/proxy"
# max cache storage
CacheSize 50000000
# hour: every 4 hour
CacheGcInterval 4
# max page expire time: hour
CacheMaxExpire 240
# Expire time = (now - last_modified) * CacheLastModifiedFactor
CacheLastModifiedFactor 0.1
# defalt expire tag: hour
CacheDefaultExpire 1
# force complete after precent of content retrived: 60-90%
CacheForceCompletion 80
CustomLog /usr/local/apache/logs/dev_access_log combined
</VirtualHost>
基於Squid的反向代理加速實現
Squid是一個更專用的代理服務器，性能和效率會比Apache的mod_proxy高很多。如果需要combined格式日誌補丁：
http://www.squid-cache.org/mail-archive/squid-dev/200301/0164.html
squid的編譯：
./configure --enable-useragent-log --enable-referer-log --enable-default-err-language=Simplify_Chinese / --enable-err-languages="Simplify_Chinese English" --disable-internal-dns
make
#make install
#cd /usr/local/squid
make dir cache
chown squid.squid *
vi /usr/local/squid/etc/squid.conf
在/etc/hosts中：加入內部的DNS解析，比如：
192.168.0.4 www.chedong.com
192.168.0.4 news.chedong.com
192.168.0.3 bbs.chedong.com
---------------------cut here----------------------------------
# visible name
visible_hostname cache.example.com
# cache config: space use 1G and memory use 256M
cache_dir ufs /usr/local/squid/cache 1024 16 256
cache_mem 256 MB
cache_effective_user squid
cache_effective_group squid
http_port 80
httpd_accel_host virtual
httpd_accel_single_host off
httpd_accel_port 80
httpd_accel_uses_host_header on
httpd_accel_with_proxy on
# accelerater my domain only
acl acceleratedHostA dstdomain .example1.com
acl acceleratedHostB dstdomain .example2.com
acl acceleratedHostC dstdomain .example3.com
# accelerater http protocol on port 80
acl acceleratedProtocol protocol HTTP
acl acceleratedPort port 80
# access arc
acl all src 0.0.0.0/0.0.0.0
# Allow requests when they are to the accelerated machine AND to the
# right port with right protocol
http_access allow acceleratedProtocol acceleratedPort acceleratedHostA
http_access allow acceleratedProtocol acceleratedPort acceleratedHostB
http_access allow acceleratedProtocol acceleratedPort acceleratedHostC
# logging
emulate_httpd_log on
cache_store_log none
# manager
acl manager proto cache_object
http_access allow manager all
cachemgr_passwd pass all
----------------------cut here---------------------------------
創建緩存目錄：
/usr/local/squid/sbin/squid -z
啓動squid
/usr/local/squid/sbin/squid
停止squid：
/usr/local/squid/sbin/squid -k shutdown
啓用新配置：
/usr/local/squid/sbin/squid -k reconfig
通過crontab每天0點截斷/輪循日誌：
0 0 * * * (/usr/local/squid/sbin/squid -k rotate)
可緩存的動態頁面設計
什麼樣的頁面能夠比較好的被緩存服務器緩存呢？如果返回內容的HTTP HEADER中有"Last-Modified"和"Expires"相關聲明，比如：Last-Modified: Wed, 14 May 2003 13:06:17 GMT
Expires: Fri, 16 Jun 2003 13:06:17 GMT
前端緩存服務器在期間會將生成的頁面緩存在本地：硬盤或者內存中，直至上述頁面過期。
因此，一個可緩存的頁面：
- 頁面必須包含Last-Modified: 標記
一般純靜態頁面本身都會有Last-Modified信息，動態頁面需要通過函數強制加上，比如在PHP中：
// always modified now
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); - 必須有Expires或Cache-Control: max-age標記設置頁面的過期時間：
對於靜態頁面，通過apache的mod_expires根據頁面的MIME類型設置緩存週期：比如圖片缺省是1個月，HTML頁面缺省是2天等。
<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/gif "access plus 1 month"
ExpiresByType text/css "now plus 2 day"
ExpiresDefault "now plus 1 day"
</IfModule>
對於動態頁面，則可以直接通過寫入HTTP返回的頭信息，比如對於新聞首頁index.php可以是20分鐘，而對於具體的一條新聞頁面可能是1天后過期。比如：在php中加入了1個月後過期：
// Expires one month later
header("Expires: " .gmdate ("D, d M Y H:i:s", time() + 3600 * 24 * 30). " GMT"); - 如果服務器端有基於HTTP的認證，必須有Cache-Control: public標記，允許前臺
<%
' Set Expires Header in minutes
Function SetExpiresHeader(ByVal minutes)
' set Page Last-Modified Header:
' Converts date (19991022 11:08:38) to http form (Fri, 22 Oct 1999 12:08:38 GMT)
Response.AddHeader "Last-Modified", DateToHTTPDate(Now())
' The Page Expires in Minutes
Response.Expires = minutes
' Set cache control to externel applications
Response.CacheControl = "public"
End Function
' Converts date (19991022 11:08:38) to http form (Fri, 22 Oct 1999 12:08:38 GMT)
Function DateToHTTPDate(ByVal OleDATE)
Const GMTdiff = #08:00:00#
OleDATE = OleDATE - GMTdiff
DateToHTTPDate = engWeekDayName(OleDATE) & _
", " & Right("0" & Day(OleDATE),2) & " " & engMonthName(OleDATE) & _
" " & Year(OleDATE) & " " & Right("0" & Hour(OleDATE),2) & _
":" & Right("0" & Minute(OleDATE),2) & ":" & Right("0" & Second(OleDATE),2) & " GMT"
End Function
Function engWeekDayName(dt)
Dim Out
Select Case WeekDay(dt,1)
Case 1:Out="Sun"
Case 2:Out="Mon"
Case 3:Out="Tue"
Case 4:Out="Wed"
Case 5:Out="Thu"
Case 6:Out="Fri"
Case 7:Out="Sat"
End Select
engWeekDayName = Out
End Function
Function engMonthName(dt)
Dim Out
Select Case Month(dt)
Case 1:Out="Jan"
Case 2:Out="Feb"
Case 3:Out="Mar"
Case 4:Out="Apr"
Case 5:Out="May"
Case 6:Out="Jun"
Case 7:Out="Jul"
Case 8:Out="Aug"
Case 9:Out="Sep"
Case 10:Out="Oct"
Case 11:Out="Nov"
Case 12:Out="Dec"
End Select
engMonthName = Out
End Function
%>
然後在具體的頁面中，比如index.asp和news.asp的“最上面”加入以下代碼：HTTP Header
<!--#include file="../include.asp"-->
<%
'頁面將被設置20分鐘後過期
SetExpiresHeader(20)
%>
應用的緩存兼容性設計
經過代理以後，由於在客戶端和服務之間增加了中間層，因此服務器無法直接拿到客戶端的IP，服務器端應用也無法直接通過轉發請求的地址返回給客戶端。但是在轉發請求的HTTD頭信息中，增加了HTTP_X_FORWARDED_????信息。用以跟蹤原有的客戶端IP地址和原來客戶端請求的服務器地址：
下面是2個例子，用於說明緩存兼容性應用的設計原則：
'對於一個需要服務器名的地址的ASP應用：不要直接引用HTTP_HOST/SERVER_NAME，判斷一下是否有HTTP_X_FORWARDED_SERVER
function getHostName ()
dim hostName as String = ""
hostName = Request.ServerVariables("HTTP_HOST")
if not isDBNull(Request.ServerVariables("HTTP_X_FORWARDED_HOST")) then
if len(trim(Request.ServerVariables("HTTP_X_FORWARDED_HOST"))) > 0 then
hostName = Request.ServerVariables("HTTP_X_FORWARDED_HOST")
end if
end if
return hostNmae
end function
//對於一個需要記錄客戶端IP的PHP應用：不要直接引用REMOTE_ADDR，而是要使用HTTP_X_FORWARDED_FOR，
function getUserIP (){
$user_ip =
內容摘要：
對於一個日訪問量達到百萬級的網站來說，速度很快就成爲一個瓶頸。除了優化內容發佈系統的應用本身外，如果能把不需要實時更新的動態頁面的輸出結果轉化成靜態網頁來發布，速度上的提升效果將是顯著的，因爲一個動態頁面的速度往往會比靜態頁面慢2－10倍，而靜態網頁的內容如果能被緩存在內存裏，訪問速度甚至會比原有動態網頁有2－3個數量級的提高。
- 動態緩存和靜態緩存的比較
- 基於反向代理加速的站點規劃
- 基於apache mod_proxy的反向代理加速實現
- 基於squid的反向代理加速實現
- 面向緩存的頁面設計
- 應用的緩存兼容性設計：
HTTP_HOST/SERVER_NAME和REMOTE_ADDR/REMOTE_HOST需要用 HTTP_X_FORWARDED_HOST/HTTP_X_FORWARDED_SERVER代替
靜態緩存和動態緩存的比較
靜態頁面的緩存可能有2種形式：其實主要區別就是CMS是否自己負責關聯內容的緩存更新管理。
- 靜態緩存：是在新內容發佈的同時就立刻生成相應內容的靜態頁面，比如：2003年3月22日，管理員通過後臺內容管理界面錄入一篇文章後，就立刻生成http://www.chedong.com/tech/2003/03/22/001.html這個靜態頁面，並同步更新相關索引頁上的鏈接。
- 動態緩存：是在新內容發佈以後，並不預先生成相應的靜態頁面，直到對相應內容發出請求時，如果前臺緩存服務器找不到相應緩存，就向後臺內容管理服務器發出請求，後臺系統會生成相應內容的靜態頁面，用戶第一次訪問頁面時可能會慢一點，但是以後就是直接訪問緩存了。
如果去ZDNet等國外網站會發現他們使用的基於Vignette內容管理系統都有這樣的頁面名稱：0,22342566,300458.html。其實這裏的0,22342566,300458就是用逗號分割開的多個參數：
第一次訪問找不到頁面後，相當於會在服務器端產生一個doc_type= 0&doc_id=22342566&doc_template=300458的查詢，
而查詢結果會生成的緩存的靜態頁面： 0,22342566,300458.html
靜態緩存的缺點：
- 複雜的觸發更新機制：這兩種機制在內容管理系統比較簡單的時候都是非常適用的。但對於一個關係比較複雜的網站來說，頁面之間的邏輯引用關係就成爲一個非常非常複雜的問題。最典型的例子就是一條新聞要同時出現在新聞首頁和相關的3個新聞專題中，在靜態緩存模式中，每發一篇新文章，除了這篇新聞內容本身的頁面外，還需要系統通過觸發器生成多個新的相關靜態頁面，這些相關邏輯的觸發也往往就會成爲內容管理系統中最複雜的部分之一。
- 舊內容的批量更新： 通過靜態緩存發佈的內容，對於以前生成的靜態頁面的內容很難修改，這樣用戶訪問舊頁面時，新的模板根本無法生效。
在動態緩存模式中，每個動態頁面只需要關心，而相關的其他頁面能自動更新，從而大大減少了設計相關頁面更新觸發器的需要。
以前做小型應用的時候也用過類似方式：應用首次訪問以後將數據庫的查詢結果在本地存成一個文件，下次請求時先檢查本地緩存目錄中是否有緩存文件，從而減少對後臺數據庫的訪問。雖然這樣做也能承載比較大的負載，但這樣的內容管理和緩存管理一體的系統是很難分離的，而且數據完整性也不是很好保存，內容更新時，應用需要把相應內容的的緩存文件刪除。但是這樣的設計在緩存文件很多的時候往往還需要將緩存目錄做一定的分佈，否則一個目錄下的文件節點超過3000，rm *都會出錯。
這時候，系統需要再次分工，把複雜的內容管理系統分解成：內容輸入和緩存這2個相對簡單的系統實現。
- 後臺：內容管理系統，專心的將內容發佈做好，比如：複雜的工作流管理，複雜的模板規則等……
- 前臺：頁面的緩存管理則可以使用緩存系統實現
______________________ ___________________
|Squid Software cache| |F5 Hardware cache|
---------------------- -------------------
/ /
/ ________________ /
|ASP |JSP |PHP |
Content Manage System
----------------
所以分工後：內容管理和緩存管理2者，無論哪一方面可選的餘地都是非常大的：軟件（比如前臺80端口使用SQUID對後臺8080的內容發佈管理系統進行緩存），緩存硬件，甚至交給akamai這樣的專業服務商。
面向緩存的站點規劃
一個利用SQUID對多個站點進行做WEB加速http acceleration方案：原先一個站點的規劃可能是這樣的：
200.200.200.207 www.chedong.com
200.200.200.208 news.chedong.com
200.200.200.209 bbs.chedong.com
200.200.200.205 images.chedong.com
面向緩存服務器的設計中：所有站點都通過外部DNS指向到同一個IP：200.200.200.200/201這2臺緩存服務器上（使用2臺是爲了冗餘備份）
_____________________ ________工作原理：
www.chedong.com 請求 / | cache box | | | / 192.168.0.4 www.chedong.com
news.chedong.com 請求 -| 200.200.200.200/201 |-|firewall| - 192.168.0.4 news.chedong.com
bbs.chedong.com 請求 / | /etc/hosts | | box | / 192.168.0.3 bbs.chedong.com
--------------------- --------
外部請求過來時，設置緩存根據配置文件進行轉向解析。這樣，服務器請求就可以轉發到我們指定的內部地址上。
在處理多虛擬主機轉向方面：mod_proxy比squid要簡單一些：可以把不同服務轉向後後臺多個IP的不同端口上。
而squid只能通過禁用DNS解析，然後根據本地的/etc/hosts文件根據請求的域名進行地址轉發，後臺多個服務器必須使用相同的端口。
使用反向代理加速，我們不僅可以得到性能上的提升，而且還能獲得額外的安全性和配置的靈活度：
- 配置靈活性提高：可以自己在內部服務器上控制後臺服務器的DNS解析，當需要在服務器之間做遷移調整時，就不用大量修改外部DNS配置了，只需要修改內部DNS實現服務的調整。
- 數據安全性增加：所有後臺服務器可以很方便的被保護在防火牆內。
- 後臺應用設計複雜程度降低：原先爲了效率常常需要建立專門的圖片服務器images.chedong.com和負載比較高的應用服務器 bbs.chedong.com分離，在反向代理加速模式中，所有前臺請求都通過緩存服務器：實際上就都是靜態頁面，這樣，應用設計時就不用考慮圖片和應用本身分離了，也大大降低了後臺內容發佈系統設計的複雜程度，由於數據和應用都存放在一起，也方便了文件系統的維護和管理。
基於Apache mod_proxy的反向代理緩存加速實現
Apache包含了mod_proxy模塊，可以用來實現代理服務器，針對後臺服務器的反向加速安裝apache 1.3.x 編譯時：
--enable-shared=max --enable-module=most
注：Apache 2.x中mod_proxy已經被分離成mod_proxy和mod_cache：同時mod_cache有基於文件和基於內存的不同實現
創建/var/www/proxy，設置apache服務所用戶可寫
mod_proxy配置樣例：反相代理緩存＋緩存
架設前臺的www.example.com反向代理後臺的www.backend.com的8080端口服務。
修改：httpd.conf
<VirtualHost *>
ServerName www.example.com
ServerAdmin [email protected]
# reverse proxy setting
ProxyPass / http://www.backend.com:8080/
ProxyPassReverse / http://www.backend.com:8080/
# cache dir root
CacheRoot "/var/www/proxy"
# max cache storage
CacheSize 50000000
# hour: every 4 hour
CacheGcInterval 4
# max page expire time: hour
CacheMaxExpire 240
# Expire time = (now - last_modified) * CacheLastModifiedFactor
CacheLastModifiedFactor 0.1
# defalt expire tag: hour
CacheDefaultExpire 1
# force complete after precent of content retrived: 60-90%
CacheForceCompletion 80
CustomLog /usr/local/apache/logs/dev_access_log combined
</VirtualHost>
基於Squid的反向代理加速實現
Squid是一個更專用的代理服務器，性能和效率會比Apache的mod_proxy高很多。如果需要combined格式日誌補丁：
http://www.squid-cache.org/mail-archive/squid-dev/200301/0164.html
squid的編譯：
./configure --enable-useragent-log --enable-referer-log --enable-default-err-language=Simplify_Chinese / --enable-err-languages="Simplify_Chinese English" --disable-internal-dns
make
#make install
#cd /usr/local/squid
make dir cache
chown squid.squid *
vi /usr/local/squid/etc/squid.conf
在/etc/hosts中：加入內部的DNS解析，比如：
192.168.0.4 www.chedong.com
192.168.0.4 news.chedong.com
192.168.0.3 bbs.chedong.com
---------------------cut here----------------------------------
# visible name
visible_hostname cache.example.com
# cache config: space use 1G and memory use 256M
cache_dir ufs /usr/local/squid/cache 1024 16 256
cache_mem 256 MB
cache_effective_user squid
cache_effective_group squid
http_port 80
httpd_accel_host virtual
httpd_accel_single_host off
httpd_accel_port 80
httpd_accel_uses_host_header on
httpd_accel_with_proxy on
# accelerater my domain only
acl acceleratedHostA dstdomain .example1.com
acl acceleratedHostB dstdomain .example2.com
acl acceleratedHostC dstdomain .example3.com
# accelerater http protocol on port 80
acl acceleratedProtocol protocol HTTP
acl acceleratedPort port 80
# access arc
acl all src 0.0.0.0/0.0.0.0
# Allow requests when they are to the accelerated machine AND to the
# right port with right protocol
http_access allow acceleratedProtocol acceleratedPort acceleratedHostA
http_access allow acceleratedProtocol acceleratedPort acceleratedHostB
http_access allow acceleratedProtocol acceleratedPort acceleratedHostC
# logging
emulate_httpd_log on
cache_store_log none
# manager
acl manager proto cache_object
http_access allow manager all
cachemgr_passwd pass all
----------------------cut here---------------------------------
創建緩存目錄：
/usr/local/squid/sbin/squid -z
啓動squid
/usr/local/squid/sbin/squid
停止squid：
/usr/local/squid/sbin/squid -k shutdown
啓用新配置：
/usr/local/squid/sbin/squid -k reconfig
通過crontab每天0點截斷/輪循日誌：
0 0 * * * (/usr/local/squid/sbin/squid -k rotate)
可緩存的動態頁面設計
什麼樣的頁面能夠比較好的被緩存服務器緩存呢？如果返回內容的HTTP HEADER中有"Last-Modified"和"Expires"相關聲明，比如：Last-Modified: Wed, 14 May 2003 13:06:17 GMT
Expires: Fri, 16 Jun 2003 13:06:17 GMT
前端緩存服務器在期間會將生成的頁面緩存在本地：硬盤或者內存中，直至上述頁面過期。
因此，一個可緩存的頁面：
- 頁面必須包含Last-Modified: 標記
一般純靜態頁面本身都會有Last-Modified信息，動態頁面需要通過函數強制加上，比如在PHP中：
// always modified now
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); - 必須有Expires或Cache-Control: max-age標記設置頁面的過期時間：
對於靜態頁面，通過apache的mod_expires根據頁面的MIME類型設置緩存週期：比如圖片缺省是1個月，HTML頁面缺省是2天等。
<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/gif "access plus 1 month"
ExpiresByType text/css "now plus 2 day"
ExpiresDefault "now plus 1 day"
</IfModule>
對於動態頁面，則可以直接通過寫入HTTP返回的頭信息，比如對於新聞首頁index.php可以是20分鐘，而對於具體的一條新聞頁面可能是1天后過期。比如：在php中加入了1個月後過期：
// Expires one month later
header("Expires: " .gmdate ("D, d M Y H:i:s", time() + 3600 * 24 * 30). " GMT"); - 如果服務器端有基於HTTP的認證，必須有Cache-Control: public標記，允許前臺
<%
' Set Expires Header in minutes
Function SetExpiresHeader(ByVal minutes)
' set Page Last-Modified Header:
' Converts date (19991022 11:08:38) to http form (Fri, 22 Oct 1999 12:08:38 GMT)
Response.AddHeader "Last-Modified", DateToHTTPDate(Now())
' The Page Expires in Minutes
Response.Expires = minutes
' Set cache control to externel applications
Response.CacheControl = "public"
End Function
' Converts date (19991022 11:08:38) to http form (Fri, 22 Oct 1999 12:08:38 GMT)
Function DateToHTTPDate(ByVal OleDATE)
Const GMTdiff = #08:00:00#
OleDATE = OleDATE - GMTdiff
DateToHTTPDate = engWeekDayName(OleDATE) & _
", " & Right("0" & Day(OleDATE),2) & " " & engMonthName(OleDATE) & _
" " & Year(OleDATE) & " " & Right("0" & Hour(OleDATE),2) & _
":" & Right("0" & Minute(OleDATE),2) & ":" & Right("0" & Second(OleDATE),2) & " GMT"
End Function
Function engWeekDayName(dt)
Dim Out
Select Case WeekDay(dt,1)
Case 1:Out="Sun"
Case 2:Out="Mon"
Case 3:Out="Tue"
Case 4:Out="Wed"
Case 5:Out="Thu"
Case 6:Out="Fri"
Case 7:Out="Sat"
End Select
engWeekDayName = Out
End Function
Function engMonthName(dt)
Dim Out
Select Case Month(dt)
Case 1:Out="Jan"
Case 2:Out="Feb"
Case 3:Out="Mar"
Case 4:Out="Apr"
Case 5:Out="May"
Case 6:Out="Jun"
Case 7:Out="Jul"
Case 8:Out="Aug"
Case 9:Out="Sep"
Case 10:Out="Oct"
Case 11:Out="Nov"
Case 12:Out="Dec"
End Select
engMonthName = Out
End Function
%>
然後在具體的頁面中，比如index.asp和news.asp的“最上面”加入以下代碼：HTTP Header
<!--#include file="../include.asp"-->
<%
'頁面將被設置20分鐘後過期
SetExpiresHeader(20)
%>
應用的緩存兼容性設計
經過代理以後，由於在客戶端和服務之間增加了中間層，因此服務器無法直接拿到客戶端的IP，服務器端應用也無法直接通過轉發請求的地址返回給客戶端。但是在轉發請求的HTTD頭信息中，增加了HTTP_X_FORWARDED_????信息。用以跟蹤原有的客戶端IP地址和原來客戶端請求的服務器地址：
下面是2個例子，用於說明緩存兼容性應用的設計原則：
___FCKpd___2
注意：HTTP_X_FORWARDED_FOR如果經過了多箇中間代理服務器，有何能是逗號分割的多個地址，
比如：200.28.7.155,200.10.225.77 unknown,219.101.137.3
因此在很多舊的數據庫設計中（比如BBS）往往用來記錄客戶端地址的字段被設置成20個字節就顯得過小了。
經常見到類似以下的錯誤信息：
Microsoft JET Database Engine 錯誤 '80040e57'
字段太小而不能接受所要添加的數據的數量。試着插入或粘貼較少的數據。
/inc/char.asp，行236
原因就是在設計客戶端訪問地址時，相關用戶IP字段大小最好要設計到50個字節以上，當然經過3層以上代理的機率也非常小。如何檢查目前站點頁面的可緩存性（Cacheablility）呢？可以參考以下2個站點上的工具：
http://www.ircache.net/cgi-bin/cacheability.py
附：SQUID性能測試試驗
phpMan.php是一個基於php的man page server，每個man
page需要調用後臺的man命令和很多頁面格式化工具，系統負載比較高，提供了Cache
Friendly的URL，以下是針對同樣的頁面的性能測試資料：
測試環境：Redhat 8 on Cyrix 266 / 192M Mem
測試程序：使用apache的ab(apache benchmark)：
測試條件：請求50次，併發50個連接
測試項目：直接通過apache 1.3 (80端口) vs squid 2.5(8000端口：加速80端口)
測試1：無CACHE的80端口動態輸出：
ab -n 100 -c 10 http://www.chedong.com:81/phpMan.php/man/kill/1
This is ApacheBench, Version 1.3d <$Revision: 1.2 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2001 The Apache Group, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software:
Apache/1.3.23
Server Hostname: localhost
Server
Port:
80
Document Path:
/phpMan.php/man/kill/1
Document Length: 4655 bytes
Concurrency Level: 5
Time taken for tests: 63.164 seconds
Complete requests: 50
Failed requests: 0
Broken pipe errors: 0
Total transferred: 245900 bytes
HTML transferred: 232750 bytes
Requests per second: 0.79 [#/sec] (mean)
Time per request: 6316.40 [ms]
(mean)
Time per request: 1263.28 [ms]
(mean, across all concurrent requests)
Transfer rate:
3.89 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0
29 106.1 0 553
Processing: 2942 6016
1845.4 6227 10796
Waiting:
2941 5999 1850.7 6226 10795
Total:
2942 6045 1825.9 6227 10796
Percentage of the requests served within a certain time (ms)
50% 6227
66% 7069
75% 7190
80% 7474
90% 8195
95% 8898
98% 9721
99% 10796
100% 10796 (last request)
測試2：SQUID緩存輸出
/home/apache/bin/ab -n50 -c5
"http://localhost:8000/phpMan.php/man/kill/1"
This is ApacheBench, Version 1.3d <$Revision: 1.2 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2001 The Apache Group, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software:
Apache/1.3.23
Server Hostname: localhost
Server
Port:
8000
Document Path:
/phpMan.php/man/kill/1
Document Length: 4655 bytes
Concurrency Level: 5
Time taken for tests: 4.265 seconds
Complete requests: 50
Failed requests: 0
Broken pipe errors: 0
Total transferred: 248043 bytes
HTML transferred: 232750 bytes
Requests per second: 11.72 [#/sec] (mean)
Time per request: 426.50 [ms] (mean)
Time per request: 85.30 [ms] (mean,
across all concurrent requests)
Transfer rate:
58.16 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect:
0 1
9.5 0 68
Processing:
7 83 537.4
7 3808
Waiting:
5 81 529.1
6 3748
Total:
7 84 547.0
7 3876
Percentage of the requests served within a certain time (ms)
50% 7
66% 7
75% 7
80% 7
90% 7
95% 7
98% 8
99% 3876
100% 3876 (last request)
結論：No Cache / Cache = 6045 / 84 = 70
結論：對於可能被緩存請求的頁面，服務器速度可以有2個數量級的提高，因爲SQUID是把緩存頁面放在內存裏的（因此幾乎沒有硬盤I/O操作）。
小節：
- 大訪問量的網站應儘可能將動態網頁生成靜態頁面作爲緩存發佈，甚至對於搜索引擎這樣的動態應用來說，緩存機制也是非常非常重要的。
- 在動態頁面中利用HTTP Header定義緩存更新策略。
- 利用緩存服務器獲得額外的配置和安全性
- 日誌非常重要：SQUID日誌缺省不支持COMBINED日誌，但對於需要REFERER日誌的這個補丁非常重要：http://www.squid-cache.org/mail-archive/squid-dev/200301/0164.html
參考資料：
HTTP代理緩存
http://vancouver-webpages.com/proxy.html
可緩存的頁面設計
http://linux.oreillynet.com/pub/a/linux/2002/02/28/cachefriendly.html
運用ASP.NET的輸出緩衝來存儲動態頁面 - 開發者 - ZDNet China
http://www.zdnet.com.cn/developer/tech/story/0,2000081602,39110239-2,00.htm
相關RFC文檔：
- RFC
2616:- section
13 (Caching) - section
14.9 (Cache-Control header) - section
14.21 (Expires header) - section
14.32 (Pragma: no-cache) is important if you are interacting with
HTTP/1.0 caches - section
14.29 (Last-Modified) is the most common validation method - section
3.11 (Entity Tags) covers the extra validation method
可緩存性檢查
http://www.web-caching.com/cacheability.html
緩存設計要素
http://vancouver-webpages.com/CacheNow/detail.html
ZOPE上的幾篇使用APACHE MOD_PROXY MOD_GZIP加速的文檔
http://www.zope.org/Members/anser/apache_zserver/
http://www.zope.org/Members/softsign/ZServer_and_Apache_mod_gzip
http://www.zope.org/Members/rbeer/caching
SERVER["REMOTE_ADDR"];
if (
內容摘要：
對於一個日訪問量達到百萬級的網站來說，速度很快就成爲一個瓶頸。除了優化內容發佈系統的應用本身外，如果能把不需要實時更新的動態頁面的輸出結果轉化成靜態網頁來發布，速度上的提升效果將是顯著的，因爲一個動態頁面的速度往往會比靜態頁面慢2－10倍，而靜態網頁的內容如果能被緩存在內存裏，訪問速度甚至會比原有動態網頁有2－3個數量級的提高。
- 動態緩存和靜態緩存的比較
- 基於反向代理加速的站點規劃
- 基於apache mod_proxy的反向代理加速實現
- 基於squid的反向代理加速實現
- 面向緩存的頁面設計
- 應用的緩存兼容性設計：
HTTP_HOST/SERVER_NAME和REMOTE_ADDR/REMOTE_HOST需要用 HTTP_X_FORWARDED_HOST/HTTP_X_FORWARDED_SERVER代替
靜態緩存和動態緩存的比較
靜態頁面的緩存可能有2種形式：其實主要區別就是CMS是否自己負責關聯內容的緩存更新管理。
- 靜態緩存：是在新內容發佈的同時就立刻生成相應內容的靜態頁面，比如：2003年3月22日，管理員通過後臺內容管理界面錄入一篇文章後，就立刻生成http://www.chedong.com/tech/2003/03/22/001.html這個靜態頁面，並同步更新相關索引頁上的鏈接。
- 動態緩存：是在新內容發佈以後，並不預先生成相應的靜態頁面，直到對相應內容發出請求時，如果前臺緩存服務器找不到相應緩存，就向後臺內容管理服務器發出請求，後臺系統會生成相應內容的靜態頁面，用戶第一次訪問頁面時可能會慢一點，但是以後就是直接訪問緩存了。
如果去ZDNet等國外網站會發現他們使用的基於Vignette內容管理系統都有這樣的頁面名稱：0,22342566,300458.html。其實這裏的0,22342566,300458就是用逗號分割開的多個參數：
第一次訪問找不到頁面後，相當於會在服務器端產生一個doc_type= 0&doc_id=22342566&doc_template=300458的查詢，
而查詢結果會生成的緩存的靜態頁面： 0,22342566,300458.html
靜態緩存的缺點：
- 複雜的觸發更新機制：這兩種機制在內容管理系統比較簡單的時候都是非常適用的。但對於一個關係比較複雜的網站來說，頁面之間的邏輯引用關係就成爲一個非常非常複雜的問題。最典型的例子就是一條新聞要同時出現在新聞首頁和相關的3個新聞專題中，在靜態緩存模式中，每發一篇新文章，除了這篇新聞內容本身的頁面外，還需要系統通過觸發器生成多個新的相關靜態頁面，這些相關邏輯的觸發也往往就會成爲內容管理系統中最複雜的部分之一。
- 舊內容的批量更新： 通過靜態緩存發佈的內容，對於以前生成的靜態頁面的內容很難修改，這樣用戶訪問舊頁面時，新的模板根本無法生效。
在動態緩存模式中，每個動態頁面只需要關心，而相關的其他頁面能自動更新，從而大大減少了設計相關頁面更新觸發器的需要。
以前做小型應用的時候也用過類似方式：應用首次訪問以後將數據庫的查詢結果在本地存成一個文件，下次請求時先檢查本地緩存目錄中是否有緩存文件，從而減少對後臺數據庫的訪問。雖然這樣做也能承載比較大的負載，但這樣的內容管理和緩存管理一體的系統是很難分離的，而且數據完整性也不是很好保存，內容更新時，應用需要把相應內容的的緩存文件刪除。但是這樣的設計在緩存文件很多的時候往往還需要將緩存目錄做一定的分佈，否則一個目錄下的文件節點超過3000，rm *都會出錯。
這時候，系統需要再次分工，把複雜的內容管理系統分解成：內容輸入和緩存這2個相對簡單的系統實現。
- 後臺：內容管理系統，專心的將內容發佈做好，比如：複雜的工作流管理，複雜的模板規則等……
- 前臺：頁面的緩存管理則可以使用緩存系統實現
______________________ ___________________
|Squid Software cache| |F5 Hardware cache|
---------------------- -------------------
/ /
/ ________________ /
|ASP |JSP |PHP |
Content Manage System
----------------
所以分工後：內容管理和緩存管理2者，無論哪一方面可選的餘地都是非常大的：軟件（比如前臺80端口使用SQUID對後臺8080的內容發佈管理系統進行緩存），緩存硬件，甚至交給akamai這樣的專業服務商。
面向緩存的站點規劃
一個利用SQUID對多個站點進行做WEB加速http acceleration方案：原先一個站點的規劃可能是這樣的：
200.200.200.207 www.chedong.com
200.200.200.208 news.chedong.com
200.200.200.209 bbs.chedong.com
200.200.200.205 images.chedong.com
面向緩存服務器的設計中：所有站點都通過外部DNS指向到同一個IP：200.200.200.200/201這2臺緩存服務器上（使用2臺是爲了冗餘備份）
_____________________ ________工作原理：
www.chedong.com 請求 / | cache box | | | / 192.168.0.4 www.chedong.com
news.chedong.com 請求 -| 200.200.200.200/201 |-|firewall| - 192.168.0.4 news.chedong.com
bbs.chedong.com 請求 / | /etc/hosts | | box | / 192.168.0.3 bbs.chedong.com
--------------------- --------
外部請求過來時，設置緩存根據配置文件進行轉向解析。這樣，服務器請求就可以轉發到我們指定的內部地址上。
在處理多虛擬主機轉向方面：mod_proxy比squid要簡單一些：可以把不同服務轉向後後臺多個IP的不同端口上。
而squid只能通過禁用DNS解析，然後根據本地的/etc/hosts文件根據請求的域名進行地址轉發，後臺多個服務器必須使用相同的端口。
使用反向代理加速，我們不僅可以得到性能上的提升，而且還能獲得額外的安全性和配置的靈活度：
- 配置靈活性提高：可以自己在內部服務器上控制後臺服務器的DNS解析，當需要在服務器之間做遷移調整時，就不用大量修改外部DNS配置了，只需要修改內部DNS實現服務的調整。
- 數據安全性增加：所有後臺服務器可以很方便的被保護在防火牆內。
- 後臺應用設計複雜程度降低：原先爲了效率常常需要建立專門的圖片服務器images.chedong.com和負載比較高的應用服務器 bbs.chedong.com分離，在反向代理加速模式中，所有前臺請求都通過緩存服務器：實際上就都是靜態頁面，這樣，應用設計時就不用考慮圖片和應用本身分離了，也大大降低了後臺內容發佈系統設計的複雜程度，由於數據和應用都存放在一起，也方便了文件系統的維護和管理。
基於Apache mod_proxy的反向代理緩存加速實現
Apache包含了mod_proxy模塊，可以用來實現代理服務器，針對後臺服務器的反向加速安裝apache 1.3.x 編譯時：
--enable-shared=max --enable-module=most
注：Apache 2.x中mod_proxy已經被分離成mod_proxy和mod_cache：同時mod_cache有基於文件和基於內存的不同實現
創建/var/www/proxy，設置apache服務所用戶可寫
mod_proxy配置樣例：反相代理緩存＋緩存
架設前臺的www.example.com反向代理後臺的www.backend.com的8080端口服務。
修改：httpd.conf
<VirtualHost *>
ServerName www.example.com
ServerAdmin [email protected]
# reverse proxy setting
ProxyPass / http://www.backend.com:8080/
ProxyPassReverse / http://www.backend.com:8080/
# cache dir root
CacheRoot "/var/www/proxy"
# max cache storage
CacheSize 50000000
# hour: every 4 hour
CacheGcInterval 4
# max page expire time: hour
CacheMaxExpire 240
# Expire time = (now - last_modified) * CacheLastModifiedFactor
CacheLastModifiedFactor 0.1
# defalt expire tag: hour
CacheDefaultExpire 1
# force complete after precent of content retrived: 60-90%
CacheForceCompletion 80
CustomLog /usr/local/apache/logs/dev_access_log combined
</VirtualHost>
基於Squid的反向代理加速實現
Squid是一個更專用的代理服務器，性能和效率會比Apache的mod_proxy高很多。如果需要combined格式日誌補丁：
http://www.squid-cache.org/mail-archive/squid-dev/200301/0164.html
squid的編譯：
./configure --enable-useragent-log --enable-referer-log --enable-default-err-language=Simplify_Chinese / --enable-err-languages="Simplify_Chinese English" --disable-internal-dns
make
#make install
#cd /usr/local/squid
make dir cache
chown squid.squid *
vi /usr/local/squid/etc/squid.conf
在/etc/hosts中：加入內部的DNS解析，比如：
192.168.0.4 www.chedong.com
192.168.0.4 news.chedong.com
192.168.0.3 bbs.chedong.com
---------------------cut here----------------------------------
# visible name
visible_hostname cache.example.com
# cache config: space use 1G and memory use 256M
cache_dir ufs /usr/local/squid/cache 1024 16 256
cache_mem 256 MB
cache_effective_user squid
cache_effective_group squid
http_port 80
httpd_accel_host virtual
httpd_accel_single_host off
httpd_accel_port 80
httpd_accel_uses_host_header on
httpd_accel_with_proxy on
# accelerater my domain only
acl acceleratedHostA dstdomain .example1.com
acl acceleratedHostB dstdomain .example2.com
acl acceleratedHostC dstdomain .example3.com
# accelerater http protocol on port 80
acl acceleratedProtocol protocol HTTP
acl acceleratedPort port 80
# access arc
acl all src 0.0.0.0/0.0.0.0
# Allow requests when they are to the accelerated machine AND to the
# right port with right protocol
http_access allow acceleratedProtocol acceleratedPort acceleratedHostA
http_access allow acceleratedProtocol acceleratedPort acceleratedHostB
http_access allow acceleratedProtocol acceleratedPort acceleratedHostC
# logging
emulate_httpd_log on
cache_store_log none
# manager
acl manager proto cache_object
http_access allow manager all
cachemgr_passwd pass all
----------------------cut here---------------------------------
創建緩存目錄：
/usr/local/squid/sbin/squid -z
啓動squid
/usr/local/squid/sbin/squid
停止squid：
/usr/local/squid/sbin/squid -k shutdown
啓用新配置：
/usr/local/squid/sbin/squid -k reconfig
通過crontab每天0點截斷/輪循日誌：
0 0 * * * (/usr/local/squid/sbin/squid -k rotate)
可緩存的動態頁面設計
什麼樣的頁面能夠比較好的被緩存服務器緩存呢？如果返回內容的HTTP HEADER中有"Last-Modified"和"Expires"相關聲明，比如：Last-Modified: Wed, 14 May 2003 13:06:17 GMT
Expires: Fri, 16 Jun 2003 13:06:17 GMT
前端緩存服務器在期間會將生成的頁面緩存在本地：硬盤或者內存中，直至上述頁面過期。
因此，一個可緩存的頁面：
- 頁面必須包含Last-Modified: 標記
一般純靜態頁面本身都會有Last-Modified信息，動態頁面需要通過函數強制加上，比如在PHP中：
// always modified now
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); - 必須有Expires或Cache-Control: max-age標記設置頁面的過期時間：
對於靜態頁面，通過apache的mod_expires根據頁面的MIME類型設置緩存週期：比如圖片缺省是1個月，HTML頁面缺省是2天等。
<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/gif "access plus 1 month"
ExpiresByType text/css "now plus 2 day"
ExpiresDefault "now plus 1 day"
</IfModule>
對於動態頁面，則可以直接通過寫入HTTP返回的頭信息，比如對於新聞首頁index.php可以是20分鐘，而對於具體的一條新聞頁面可能是1天后過期。比如：在php中加入了1個月後過期：
// Expires one month later
header("Expires: " .gmdate ("D, d M Y H:i:s", time() + 3600 * 24 * 30). " GMT"); - 如果服務器端有基於HTTP的認證，必須有Cache-Control: public標記，允許前臺
<%
' Set Expires Header in minutes
Function SetExpiresHeader(ByVal minutes)
' set Page Last-Modified Header:
' Converts date (19991022 11:08:38) to http form (Fri, 22 Oct 1999 12:08:38 GMT)
Response.AddHeader "Last-Modified", DateToHTTPDate(Now())
' The Page Expires in Minutes
Response.Expires = minutes
' Set cache control to externel applications
Response.CacheControl = "public"
End Function
' Converts date (19991022 11:08:38) to http form (Fri, 22 Oct 1999 12:08:38 GMT)
Function DateToHTTPDate(ByVal OleDATE)
Const GMTdiff = #08:00:00#
OleDATE = OleDATE - GMTdiff
DateToHTTPDate = engWeekDayName(OleDATE) & _
", " & Right("0" & Day(OleDATE),2) & " " & engMonthName(OleDATE) & _
" " & Year(OleDATE) & " " & Right("0" & Hour(OleDATE),2) & _
":" & Right("0" & Minute(OleDATE),2) & ":" & Right("0" & Second(OleDATE),2) & " GMT"
End Function
Function engWeekDayName(dt)
Dim Out
Select Case WeekDay(dt,1)
Case 1:Out="Sun"
Case 2:Out="Mon"
Case 3:Out="Tue"
Case 4:Out="Wed"
Case 5:Out="Thu"
Case 6:Out="Fri"
Case 7:Out="Sat"
End Select
engWeekDayName = Out
End Function
Function engMonthName(dt)
Dim Out
Select Case Month(dt)
Case 1:Out="Jan"
Case 2:Out="Feb"
Case 3:Out="Mar"
Case 4:Out="Apr"
Case 5:Out="May"
Case 6:Out="Jun"
Case 7:Out="Jul"
Case 8:Out="Aug"
Case 9:Out="Sep"
Case 10:Out="Oct"
Case 11:Out="Nov"
Case 12:Out="Dec"
End Select
engMonthName = Out
End Function
%>
然後在具體的頁面中，比如index.asp和news.asp的“最上面”加入以下代碼：HTTP Header
<!--#include file="../include.asp"-->
<%
'頁面將被設置20分鐘後過期
SetExpiresHeader(20)
%>
應用的緩存兼容性設計
經過代理以後，由於在客戶端和服務之間增加了中間層，因此服務器無法直接拿到客戶端的IP，服務器端應用也無法直接通過轉發請求的地址返回給客戶端。但是在轉發請求的HTTD頭信息中，增加了HTTP_X_FORWARDED_????信息。用以跟蹤原有的客戶端IP地址和原來客戶端請求的服務器地址：
下面是2個例子，用於說明緩存兼容性應用的設計原則：
___FCKpd___2
注意：HTTP_X_FORWARDED_FOR如果經過了多箇中間代理服務器，有何能是逗號分割的多個地址，
比如：200.28.7.155,200.10.225.77 unknown,219.101.137.3
因此在很多舊的數據庫設計中（比如BBS）往往用來記錄客戶端地址的字段被設置成20個字節就顯得過小了。
經常見到類似以下的錯誤信息：
Microsoft JET Database Engine 錯誤 '80040e57'
字段太小而不能接受所要添加的數據的數量。試着插入或粘貼較少的數據。
/inc/char.asp，行236
原因就是在設計客戶端訪問地址時，相關用戶IP字段大小最好要設計到50個字節以上，當然經過3層以上代理的機率也非常小。如何檢查目前站點頁面的可緩存性（Cacheablility）呢？可以參考以下2個站點上的工具：
http://www.ircache.net/cgi-bin/cacheability.py
附：SQUID性能測試試驗
phpMan.php是一個基於php的man page server，每個man
page需要調用後臺的man命令和很多頁面格式化工具，系統負載比較高，提供了Cache
Friendly的URL，以下是針對同樣的頁面的性能測試資料：
測試環境：Redhat 8 on Cyrix 266 / 192M Mem
測試程序：使用apache的ab(apache benchmark)：
測試條件：請求50次，併發50個連接
測試項目：直接通過apache 1.3 (80端口) vs squid 2.5(8000端口：加速80端口)
測試1：無CACHE的80端口動態輸出：
ab -n 100 -c 10 http://www.chedong.com:81/phpMan.php/man/kill/1
This is ApacheBench, Version 1.3d <$Revision: 1.2 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2001 The Apache Group, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software:
Apache/1.3.23
Server Hostname: localhost
Server
Port:
80
Document Path:
/phpMan.php/man/kill/1
Document Length: 4655 bytes
Concurrency Level: 5
Time taken for tests: 63.164 seconds
Complete requests: 50
Failed requests: 0
Broken pipe errors: 0
Total transferred: 245900 bytes
HTML transferred: 232750 bytes
Requests per second: 0.79 [#/sec] (mean)
Time per request: 6316.40 [ms]
(mean)
Time per request: 1263.28 [ms]
(mean, across all concurrent requests)
Transfer rate:
3.89 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0
29 106.1 0 553
Processing: 2942 6016
1845.4 6227 10796
Waiting:
2941 5999 1850.7 6226 10795
Total:
2942 6045 1825.9 6227 10796
Percentage of the requests served within a certain time (ms)
50% 6227
66% 7069
75% 7190
80% 7474
90% 8195
95% 8898
98% 9721
99% 10796
100% 10796 (last request)
測試2：SQUID緩存輸出
/home/apache/bin/ab -n50 -c5
"http://localhost:8000/phpMan.php/man/kill/1"
This is ApacheBench, Version 1.3d <$Revision: 1.2 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2001 The Apache Group, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software:
Apache/1.3.23
Server Hostname: localhost
Server
Port:
8000
Document Path:
/phpMan.php/man/kill/1
Document Length: 4655 bytes
Concurrency Level: 5
Time taken for tests: 4.265 seconds
Complete requests: 50
Failed requests: 0
Broken pipe errors: 0
Total transferred: 248043 bytes
HTML transferred: 232750 bytes
Requests per second: 11.72 [#/sec] (mean)
Time per request: 426.50 [ms] (mean)
Time per request: 85.30 [ms] (mean,
across all concurrent requests)
Transfer rate:
58.16 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect:
0 1
9.5 0 68
Processing:
7 83 537.4
7 3808
Waiting:
5 81 529.1
6 3748
Total:
7 84 547.0
7 3876
Percentage of the requests served within a certain time (ms)
50% 7
66% 7
75% 7
80% 7
90% 7
95% 7
98% 8
99% 3876
100% 3876 (last request)
結論：No Cache / Cache = 6045 / 84 = 70
結論：對於可能被緩存請求的頁面，服務器速度可以有2個數量級的提高，因爲SQUID是把緩存頁面放在內存裏的（因此幾乎沒有硬盤I/O操作）。
小節：
- 大訪問量的網站應儘可能將動態網頁生成靜態頁面作爲緩存發佈，甚至對於搜索引擎這樣的動態應用來說，緩存機制也是非常非常重要的。
- 在動態頁面中利用HTTP Header定義緩存更新策略。
- 利用緩存服務器獲得額外的配置和安全性
- 日誌非常重要：SQUID日誌缺省不支持COMBINED日誌，但對於需要REFERER日誌的這個補丁非常重要：http://www.squid-cache.org/mail-archive/squid-dev/200301/0164.html
參考資料：
HTTP代理緩存
http://vancouver-webpages.com/proxy.html
可緩存的頁面設計
http://linux.oreillynet.com/pub/a/linux/2002/02/28/cachefriendly.html
運用ASP.NET的輸出緩衝來存儲動態頁面 - 開發者 - ZDNet China
http://www.zdnet.com.cn/developer/tech/story/0,2000081602,39110239-2,00.htm
相關RFC文檔：
- RFC
2616:- section
13 (Caching) - section
14.9 (Cache-Control header) - section
14.21 (Expires header) - section
14.32 (Pragma: no-cache) is important if you are interacting with
HTTP/1.0 caches - section
14.29 (Last-Modified) is the most common validation method - section
3.11 (Entity Tags) covers the extra validation method
可緩存性檢查
http://www.web-caching.com/cacheability.html
緩存設計要素
http://vancouver-webpages.com/CacheNow/detail.html
ZOPE上的幾篇使用APACHE MOD_PROXY MOD_GZIP加速的文檔
http://www.zope.org/Members/anser/apache_zserver/
http://www.zope.org/Members/softsign/ZServer_and_Apache_mod_gzip
http://www.zope.org/Members/rbeer/caching
SERVER["HTTP_X_FORWARDED_FOR"]) {
$user_ip =
內容摘要：
對於一個日訪問量達到百萬級的網站來說，速度很快就成爲一個瓶頸。除了優化內容發佈系統的應用本身外，如果能把不需要實時更新的動態頁面的輸出結果轉化成靜態網頁來發布，速度上的提升效果將是顯著的，因爲一個動態頁面的速度往往會比靜態頁面慢2－10倍，而靜態網頁的內容如果能被緩存在內存裏，訪問速度甚至會比原有動態網頁有2－3個數量級的提高。
- 動態緩存和靜態緩存的比較
- 基於反向代理加速的站點規劃
- 基於apache mod_proxy的反向代理加速實現
- 基於squid的反向代理加速實現
- 面向緩存的頁面設計
- 應用的緩存兼容性設計：
HTTP_HOST/SERVER_NAME和REMOTE_ADDR/REMOTE_HOST需要用 HTTP_X_FORWARDED_HOST/HTTP_X_FORWARDED_SERVER代替
靜態緩存和動態緩存的比較
靜態頁面的緩存可能有2種形式：其實主要區別就是CMS是否自己負責關聯內容的緩存更新管理。
- 靜態緩存：是在新內容發佈的同時就立刻生成相應內容的靜態頁面，比如：2003年3月22日，管理員通過後臺內容管理界面錄入一篇文章後，就立刻生成http://www.chedong.com/tech/2003/03/22/001.html這個靜態頁面，並同步更新相關索引頁上的鏈接。
- 動態緩存：是在新內容發佈以後，並不預先生成相應的靜態頁面，直到對相應內容發出請求時，如果前臺緩存服務器找不到相應緩存，就向後臺內容管理服務器發出請求，後臺系統會生成相應內容的靜態頁面，用戶第一次訪問頁面時可能會慢一點，但是以後就是直接訪問緩存了。
如果去ZDNet等國外網站會發現他們使用的基於Vignette內容管理系統都有這樣的頁面名稱：0,22342566,300458.html。其實這裏的0,22342566,300458就是用逗號分割開的多個參數：
第一次訪問找不到頁面後，相當於會在服務器端產生一個doc_type= 0&doc_id=22342566&doc_template=300458的查詢，
而查詢結果會生成的緩存的靜態頁面： 0,22342566,300458.html
靜態緩存的缺點：
- 複雜的觸發更新機制：這兩種機制在內容管理系統比較簡單的時候都是非常適用的。但對於一個關係比較複雜的網站來說，頁面之間的邏輯引用關係就成爲一個非常非常複雜的問題。最典型的例子就是一條新聞要同時出現在新聞首頁和相關的3個新聞專題中，在靜態緩存模式中，每發一篇新文章，除了這篇新聞內容本身的頁面外，還需要系統通過觸發器生成多個新的相關靜態頁面，這些相關邏輯的觸發也往往就會成爲內容管理系統中最複雜的部分之一。
- 舊內容的批量更新： 通過靜態緩存發佈的內容，對於以前生成的靜態頁面的內容很難修改，這樣用戶訪問舊頁面時，新的模板根本無法生效。
在動態緩存模式中，每個動態頁面只需要關心，而相關的其他頁面能自動更新，從而大大減少了設計相關頁面更新觸發器的需要。
以前做小型應用的時候也用過類似方式：應用首次訪問以後將數據庫的查詢結果在本地存成一個文件，下次請求時先檢查本地緩存目錄中是否有緩存文件，從而減少對後臺數據庫的訪問。雖然這樣做也能承載比較大的負載，但這樣的內容管理和緩存管理一體的系統是很難分離的，而且數據完整性也不是很好保存，內容更新時，應用需要把相應內容的的緩存文件刪除。但是這樣的設計在緩存文件很多的時候往往還需要將緩存目錄做一定的分佈，否則一個目錄下的文件節點超過3000，rm *都會出錯。
這時候，系統需要再次分工，把複雜的內容管理系統分解成：內容輸入和緩存這2個相對簡單的系統實現。
- 後臺：內容管理系統，專心的將內容發佈做好，比如：複雜的工作流管理，複雜的模板規則等……
- 前臺：頁面的緩存管理則可以使用緩存系統實現
______________________ ___________________
|Squid Software cache| |F5 Hardware cache|
---------------------- -------------------
/ /
/ ________________ /
|ASP |JSP |PHP |
Content Manage System
----------------
所以分工後：內容管理和緩存管理2者，無論哪一方面可選的餘地都是非常大的：軟件（比如前臺80端口使用SQUID對後臺8080的內容發佈管理系統進行緩存），緩存硬件，甚至交給akamai這樣的專業服務商。
面向緩存的站點規劃
一個利用SQUID對多個站點進行做WEB加速http acceleration方案：原先一個站點的規劃可能是這樣的：
200.200.200.207 www.chedong.com
200.200.200.208 news.chedong.com
200.200.200.209 bbs.chedong.com
200.200.200.205 images.chedong.com
面向緩存服務器的設計中：所有站點都通過外部DNS指向到同一個IP：200.200.200.200/201這2臺緩存服務器上（使用2臺是爲了冗餘備份）
_____________________ ________工作原理：
www.chedong.com 請求 / | cache box | | | / 192.168.0.4 www.chedong.com
news.chedong.com 請求 -| 200.200.200.200/201 |-|firewall| - 192.168.0.4 news.chedong.com
bbs.chedong.com 請求 / | /etc/hosts | | box | / 192.168.0.3 bbs.chedong.com
--------------------- --------
外部請求過來時，設置緩存根據配置文件進行轉向解析。這樣，服務器請求就可以轉發到我們指定的內部地址上。
在處理多虛擬主機轉向方面：mod_proxy比squid要簡單一些：可以把不同服務轉向後後臺多個IP的不同端口上。
而squid只能通過禁用DNS解析，然後根據本地的/etc/hosts文件根據請求的域名進行地址轉發，後臺多個服務器必須使用相同的端口。
使用反向代理加速，我們不僅可以得到性能上的提升，而且還能獲得額外的安全性和配置的靈活度：
- 配置靈活性提高：可以自己在內部服務器上控制後臺服務器的DNS解析，當需要在服務器之間做遷移調整時，就不用大量修改外部DNS配置了，只需要修改內部DNS實現服務的調整。
- 數據安全性增加：所有後臺服務器可以很方便的被保護在防火牆內。
- 後臺應用設計複雜程度降低：原先爲了效率常常需要建立專門的圖片服務器images.chedong.com和負載比較高的應用服務器 bbs.chedong.com分離，在反向代理加速模式中，所有前臺請求都通過緩存服務器：實際上就都是靜態頁面，這樣，應用設計時就不用考慮圖片和應用本身分離了，也大大降低了後臺內容發佈系統設計的複雜程度，由於數據和應用都存放在一起，也方便了文件系統的維護和管理。
基於Apache mod_proxy的反向代理緩存加速實現
Apache包含了mod_proxy模塊，可以用來實現代理服務器，針對後臺服務器的反向加速安裝apache 1.3.x 編譯時：
--enable-shared=max --enable-module=most
注：Apache 2.x中mod_proxy已經被分離成mod_proxy和mod_cache：同時mod_cache有基於文件和基於內存的不同實現
創建/var/www/proxy，設置apache服務所用戶可寫
mod_proxy配置樣例：反相代理緩存＋緩存
架設前臺的www.example.com反向代理後臺的www.backend.com的8080端口服務。
修改：httpd.conf
<VirtualHost *>
ServerName www.example.com
ServerAdmin [email protected]
# reverse proxy setting
ProxyPass / http://www.backend.com:8080/
ProxyPassReverse / http://www.backend.com:8080/
# cache dir root
CacheRoot "/var/www/proxy"
# max cache storage
CacheSize 50000000
# hour: every 4 hour
CacheGcInterval 4
# max page expire time: hour
CacheMaxExpire 240
# Expire time = (now - last_modified) * CacheLastModifiedFactor
CacheLastModifiedFactor 0.1
# defalt expire tag: hour
CacheDefaultExpire 1
# force complete after precent of content retrived: 60-90%
CacheForceCompletion 80
CustomLog /usr/local/apache/logs/dev_access_log combined
</VirtualHost>
基於Squid的反向代理加速實現
Squid是一個更專用的代理服務器，性能和效率會比Apache的mod_proxy高很多。如果需要combined格式日誌補丁：
http://www.squid-cache.org/mail-archive/squid-dev/200301/0164.html
squid的編譯：
./configure --enable-useragent-log --enable-referer-log --enable-default-err-language=Simplify_Chinese / --enable-err-languages="Simplify_Chinese English" --disable-internal-dns
make
#make install
#cd /usr/local/squid
make dir cache
chown squid.squid *
vi /usr/local/squid/etc/squid.conf
在/etc/hosts中：加入內部的DNS解析，比如：
192.168.0.4 www.chedong.com
192.168.0.4 news.chedong.com
192.168.0.3 bbs.chedong.com
---------------------cut here----------------------------------
# visible name
visible_hostname cache.example.com
# cache config: space use 1G and memory use 256M
cache_dir ufs /usr/local/squid/cache 1024 16 256
cache_mem 256 MB
cache_effective_user squid
cache_effective_group squid
http_port 80
httpd_accel_host virtual
httpd_accel_single_host off
httpd_accel_port 80
httpd_accel_uses_host_header on
httpd_accel_with_proxy on
# accelerater my domain only
acl acceleratedHostA dstdomain .example1.com
acl acceleratedHostB dstdomain .example2.com
acl acceleratedHostC dstdomain .example3.com
# accelerater http protocol on port 80
acl acceleratedProtocol protocol HTTP
acl acceleratedPort port 80
# access arc
acl all src 0.0.0.0/0.0.0.0
# Allow requests when they are to the accelerated machine AND to the
# right port with right protocol
http_access allow acceleratedProtocol acceleratedPort acceleratedHostA
http_access allow acceleratedProtocol acceleratedPort acceleratedHostB
http_access allow acceleratedProtocol acceleratedPort acceleratedHostC
# logging
emulate_httpd_log on
cache_store_log none
# manager
acl manager proto cache_object
http_access allow manager all
cachemgr_passwd pass all
----------------------cut here---------------------------------
創建緩存目錄：
/usr/local/squid/sbin/squid -z
啓動squid
/usr/local/squid/sbin/squid
停止squid：
/usr/local/squid/sbin/squid -k shutdown
啓用新配置：
/usr/local/squid/sbin/squid -k reconfig
通過crontab每天0點截斷/輪循日誌：
0 0 * * * (/usr/local/squid/sbin/squid -k rotate)
可緩存的動態頁面設計
什麼樣的頁面能夠比較好的被緩存服務器緩存呢？如果返回內容的HTTP HEADER中有"Last-Modified"和"Expires"相關聲明，比如：Last-Modified: Wed, 14 May 2003 13:06:17 GMT
Expires: Fri, 16 Jun 2003 13:06:17 GMT
前端緩存服務器在期間會將生成的頁面緩存在本地：硬盤或者內存中，直至上述頁面過期。
因此，一個可緩存的頁面：
- 頁面必須包含Last-Modified: 標記
一般純靜態頁面本身都會有Last-Modified信息，動態頁面需要通過函數強制加上，比如在PHP中：
// always modified now
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); - 必須有Expires或Cache-Control: max-age標記設置頁面的過期時間：
對於靜態頁面，通過apache的mod_expires根據頁面的MIME類型設置緩存週期：比如圖片缺省是1個月，HTML頁面缺省是2天等。
<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/gif "access plus 1 month"
ExpiresByType text/css "now plus 2 day"
ExpiresDefault "now plus 1 day"
</IfModule>
對於動態頁面，則可以直接通過寫入HTTP返回的頭信息，比如對於新聞首頁index.php可以是20分鐘，而對於具體的一條新聞頁面可能是1天后過期。比如：在php中加入了1個月後過期：
// Expires one month later
header("Expires: " .gmdate ("D, d M Y H:i:s", time() + 3600 * 24 * 30). " GMT"); - 如果服務器端有基於HTTP的認證，必須有Cache-Control: public標記，允許前臺
<%
' Set Expires Header in minutes
Function SetExpiresHeader(ByVal minutes)
' set Page Last-Modified Header:
' Converts date (19991022 11:08:38) to http form (Fri, 22 Oct 1999 12:08:38 GMT)
Response.AddHeader "Last-Modified", DateToHTTPDate(Now())
' The Page Expires in Minutes
Response.Expires = minutes
' Set cache control to externel applications
Response.CacheControl = "public"
End Function
' Converts date (19991022 11:08:38) to http form (Fri, 22 Oct 1999 12:08:38 GMT)
Function DateToHTTPDate(ByVal OleDATE)
Const GMTdiff = #08:00:00#
OleDATE = OleDATE - GMTdiff
DateToHTTPDate = engWeekDayName(OleDATE) & _
", " & Right("0" & Day(OleDATE),2) & " " & engMonthName(OleDATE) & _
" " & Year(OleDATE) & " " & Right("0" & Hour(OleDATE),2) & _
":" & Right("0" & Minute(OleDATE),2) & ":" & Right("0" & Second(OleDATE),2) & " GMT"
End Function
Function engWeekDayName(dt)
Dim Out
Select Case WeekDay(dt,1)
Case 1:Out="Sun"
Case 2:Out="Mon"
Case 3:Out="Tue"
Case 4:Out="Wed"
Case 5:Out="Thu"
Case 6:Out="Fri"
Case 7:Out="Sat"
End Select
engWeekDayName = Out
End Function
Function engMonthName(dt)
Dim Out
Select Case Month(dt)
Case 1:Out="Jan"
Case 2:Out="Feb"
Case 3:Out="Mar"
Case 4:Out="Apr"
Case 5:Out="May"
Case 6:Out="Jun"
Case 7:Out="Jul"
Case 8:Out="Aug"
Case 9:Out="Sep"
Case 10:Out="Oct"
Case 11:Out="Nov"
Case 12:Out="Dec"
End Select
engMonthName = Out
End Function
%>
然後在具體的頁面中，比如index.asp和news.asp的“最上面”加入以下代碼：HTTP Header
<!--#include file="../include.asp"-->
<%
'頁面將被設置20分鐘後過期
SetExpiresHeader(20)
%>
應用的緩存兼容性設計
經過代理以後，由於在客戶端和服務之間增加了中間層，因此服務器無法直接拿到客戶端的IP，服務器端應用也無法直接通過轉發請求的地址返回給客戶端。但是在轉發請求的HTTD頭信息中，增加了HTTP_X_FORWARDED_????信息。用以跟蹤原有的客戶端IP地址和原來客戶端請求的服務器地址：
下面是2個例子，用於說明緩存兼容性應用的設計原則：
___FCKpd___2
注意：HTTP_X_FORWARDED_FOR如果經過了多箇中間代理服務器，有何能是逗號分割的多個地址，
比如：200.28.7.155,200.10.225.77 unknown,219.101.137.3
因此在很多舊的數據庫設計中（比如BBS）往往用來記錄客戶端地址的字段被設置成20個字節就顯得過小了。
經常見到類似以下的錯誤信息：
Microsoft JET Database Engine 錯誤 '80040e57'
字段太小而不能接受所要添加的數據的數量。試着插入或粘貼較少的數據。
/inc/char.asp，行236
原因就是在設計客戶端訪問地址時，相關用戶IP字段大小最好要設計到50個字節以上，當然經過3層以上代理的機率也非常小。如何檢查目前站點頁面的可緩存性（Cacheablility）呢？可以參考以下2個站點上的工具：
http://www.ircache.net/cgi-bin/cacheability.py
附：SQUID性能測試試驗
phpMan.php是一個基於php的man page server，每個man
page需要調用後臺的man命令和很多頁面格式化工具，系統負載比較高，提供了Cache
Friendly的URL，以下是針對同樣的頁面的性能測試資料：
測試環境：Redhat 8 on Cyrix 266 / 192M Mem
測試程序：使用apache的ab(apache benchmark)：
測試條件：請求50次，併發50個連接
測試項目：直接通過apache 1.3 (80端口) vs squid 2.5(8000端口：加速80端口)
測試1：無CACHE的80端口動態輸出：
ab -n 100 -c 10 http://www.chedong.com:81/phpMan.php/man/kill/1
This is ApacheBench, Version 1.3d <$Revision: 1.2 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2001 The Apache Group, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software:
Apache/1.3.23
Server Hostname: localhost
Server
Port:
80
Document Path:
/phpMan.php/man/kill/1
Document Length: 4655 bytes
Concurrency Level: 5
Time taken for tests: 63.164 seconds
Complete requests: 50
Failed requests: 0
Broken pipe errors: 0
Total transferred: 245900 bytes
HTML transferred: 232750 bytes
Requests per second: 0.79 [#/sec] (mean)
Time per request: 6316.40 [ms]
(mean)
Time per request: 1263.28 [ms]
(mean, across all concurrent requests)
Transfer rate:
3.89 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0
29 106.1 0 553
Processing: 2942 6016
1845.4 6227 10796
Waiting:
2941 5999 1850.7 6226 10795
Total:
2942 6045 1825.9 6227 10796
Percentage of the requests served within a certain time (ms)
50% 6227
66% 7069
75% 7190
80% 7474
90% 8195
95% 8898
98% 9721
99% 10796
100% 10796 (last request)
測試2：SQUID緩存輸出
/home/apache/bin/ab -n50 -c5
"http://localhost:8000/phpMan.php/man/kill/1"
This is ApacheBench, Version 1.3d <$Revision: 1.2 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2001 The Apache Group, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software:
Apache/1.3.23
Server Hostname: localhost
Server
Port:
8000
Document Path:
/phpMan.php/man/kill/1
Document Length: 4655 bytes
Concurrency Level: 5
Time taken for tests: 4.265 seconds
Complete requests: 50
Failed requests: 0
Broken pipe errors: 0
Total transferred: 248043 bytes
HTML transferred: 232750 bytes
Requests per second: 11.72 [#/sec] (mean)
Time per request: 426.50 [ms] (mean)
Time per request: 85.30 [ms] (mean,
across all concurrent requests)
Transfer rate:
58.16 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect:
0 1
9.5 0 68
Processing:
7 83 537.4
7 3808
Waiting:
5 81 529.1
6 3748
Total:
7 84 547.0
7 3876
Percentage of the requests served within a certain time (ms)
50% 7
66% 7
75% 7
80% 7
90% 7
95% 7
98% 8
99% 3876
100% 3876 (last request)
結論：No Cache / Cache = 6045 / 84 = 70
結論：對於可能被緩存請求的頁面，服務器速度可以有2個數量級的提高，因爲SQUID是把緩存頁面放在內存裏的（因此幾乎沒有硬盤I/O操作）。
小節：
- 大訪問量的網站應儘可能將動態網頁生成靜態頁面作爲緩存發佈，甚至對於搜索引擎這樣的動態應用來說，緩存機制也是非常非常重要的。
- 在動態頁面中利用HTTP Header定義緩存更新策略。
- 利用緩存服務器獲得額外的配置和安全性
- 日誌非常重要：SQUID日誌缺省不支持COMBINED日誌，但對於需要REFERER日誌的這個補丁非常重要：http://www.squid-cache.org/mail-archive/squid-dev/200301/0164.html
參考資料：
HTTP代理緩存
http://vancouver-webpages.com/proxy.html
可緩存的頁面設計
http://linux.oreillynet.com/pub/a/linux/2002/02/28/cachefriendly.html
運用ASP.NET的輸出緩衝來存儲動態頁面 - 開發者 - ZDNet China
http://www.zdnet.com.cn/developer/tech/story/0,2000081602,39110239-2,00.htm
相關RFC文檔：
- RFC
2616:- section
13 (Caching) - section
14.9 (Cache-Control header) - section
14.21 (Expires header) - section
14.32 (Pragma: no-cache) is important if you are interacting with
HTTP/1.0 caches - section
14.29 (Last-Modified) is the most common validation method - section
3.11 (Entity Tags) covers the extra validation method
可緩存性檢查
http://www.web-caching.com/cacheability.html
緩存設計要素
http://vancouver-webpages.com/CacheNow/detail.html
ZOPE上的幾篇使用APACHE MOD_PROXY MOD_GZIP加速的文檔
http://www.zope.org/Members/anser/apache_zserver/
http://www.zope.org/Members/softsign/ZServer_and_Apache_mod_gzip
http://www.zope.org/Members/rbeer/caching
SERVER["HTTP_X_FORWARDED_FOR"];
}
}
注意：HTTP_X_FORWARDED_FOR如果經過了多箇中間代理服務器，有何能是逗號分割的多個地址，
比如：200.28.7.155,200.10.225.77 unknown,219.101.137.3
因此在很多舊的數據庫設計中（比如BBS）往往用來記錄客戶端地址的字段被設置成20個字節就顯得過小了。
經常見到類似以下的錯誤信息：
Microsoft JET Database Engine 錯誤 '80040e57'
字段太小而不能接受所要添加的數據的數量。試着插入或粘貼較少的數據。
/inc/char.asp，行236
原因就是在設計客戶端訪問地址時，相關用戶IP字段大小最好要設計到50個字節以上，當然經過3層以上代理的機率也非常小。如何檢查目前站點頁面的可緩存性（Cacheablility）呢？可以參考以下2個站點上的工具：
http://www.ircache.net/cgi-bin/cacheability.py
附：SQUID性能測試試驗
phpMan.php是一個基於php的man page server，每個man
page需要調用後臺的man命令和很多頁面格式化工具，系統負載比較高，提供了Cache
Friendly的URL，以下是針對同樣的頁面的性能測試資料：
測試環境：Redhat 8 on Cyrix 266 / 192M Mem
測試程序：使用apache的ab(apache benchmark)：
測試條件：請求50次，併發50個連接
測試項目：直接通過apache 1.3 (80端口) vs squid 2.5(8000端口：加速80端口)
測試1：無CACHE的80端口動態輸出：
ab -n 100 -c 10 http://www.chedong.com:81/phpMan.php/man/kill/1
This is ApacheBench, Version 1.3d <$Revision: 1.2 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2001 The Apache Group, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software:
Apache/1.3.23
Server Hostname: localhost
Server
Port:
80
Document Path:
/phpMan.php/man/kill/1
Document Length: 4655 bytes
Concurrency Level: 5
Time taken for tests: 63.164 seconds
Complete requests: 50
Failed requests: 0
Broken pipe errors: 0
Total transferred: 245900 bytes
HTML transferred: 232750 bytes
Requests per second: 0.79 [#/sec] (mean)
Time per request: 6316.40 [ms]
(mean)
Time per request: 1263.28 [ms]
(mean, across all concurrent requests)
Transfer rate:
3.89 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0
29 106.1 0 553
Processing: 2942 6016
1845.4 6227 10796
Waiting:
2941 5999 1850.7 6226 10795
Total:
2942 6045 1825.9 6227 10796
Percentage of the requests served within a certain time (ms)
50% 6227
66% 7069
75% 7190
80% 7474
90% 8195
95% 8898
98% 9721
99% 10796
100% 10796 (last request)
測試2：SQUID緩存輸出
/home/apache/bin/ab -n50 -c5
"http://localhost:8000/phpMan.php/man/kill/1"
This is ApacheBench, Version 1.3d <$Revision: 1.2 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2001 The Apache Group, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software:
Apache/1.3.23
Server Hostname: localhost
Server
Port:
8000
Document Path:
/phpMan.php/man/kill/1
Document Length: 4655 bytes
Concurrency Level: 5
Time taken for tests: 4.265 seconds
Complete requests: 50
Failed requests: 0
Broken pipe errors: 0
Total transferred: 248043 bytes
HTML transferred: 232750 bytes
Requests per second: 11.72 [#/sec] (mean)
Time per request: 426.50 [ms] (mean)
Time per request: 85.30 [ms] (mean,
across all concurrent requests)
Transfer rate:
58.16 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect:
0 1
9.5 0 68
Processing:
7 83 537.4
7 3808
Waiting:
5 81 529.1
6 3748
Total:
7 84 547.0
7 3876
Percentage of the requests served within a certain time (ms)
50% 7
66% 7
75% 7
80% 7
90% 7
95% 7
98% 8
99% 3876
100% 3876 (last request)
結論：No Cache / Cache = 6045 / 84 = 70
結論：對於可能被緩存請求的頁面，服務器速度可以有2個數量級的提高，因爲SQUID是把緩存頁面放在內存裏的（因此幾乎沒有硬盤I/O操作）。
小節：
- 大訪問量的網站應儘可能將動態網頁生成靜態頁面作爲緩存發佈，甚至對於搜索引擎這樣的動態應用來說，緩存機制也是非常非常重要的。
- 在動態頁面中利用HTTP Header定義緩存更新策略。
- 利用緩存服務器獲得額外的配置和安全性
- 日誌非常重要：SQUID日誌缺省不支持COMBINED日誌，但對於需要REFERER日誌的這個補丁非常重要：http://www.squid-cache.org/mail-archive/squid-dev/200301/0164.html
參考資料：
HTTP代理緩存
http://vancouver-webpages.com/proxy.html
可緩存的頁面設計
http://linux.oreillynet.com/pub/a/linux/2002/02/28/cachefriendly.html
運用ASP.NET的輸出緩衝來存儲動態頁面 - 開發者 - ZDNet China
http://www.zdnet.com.cn/developer/tech/story/0,2000081602,39110239-2,00.htm
相關RFC文檔：
- RFC
2616:- section
13 (Caching) - section
14.9 (Cache-Control header) - section
14.21 (Expires header) - section
14.32 (Pragma: no-cache) is important if you are interacting with
HTTP/1.0 caches - section
14.29 (Last-Modified) is the most common validation method - section
3.11 (Entity Tags) covers the extra validation method
可緩存性檢查
http://www.web-caching.com/cacheability.html
緩存設計要素
http://vancouver-webpages.com/CacheNow/detail.html
ZOPE上的幾篇使用APACHE MOD_PROXY MOD_GZIP加速的文檔
http://www.zope.org/Members/anser/apache_zserver/
http://www.zope.org/Members/softsign/ZServer_and_Apache_mod_gzip
http://www.zope.org/Members/rbeer/caching