基于反向代理的Web緩存加速——可緩存的CMS系統(tǒng)設計
發(fā)表時間:2023-08-17 來源:明輝站整理相關軟件相關文章人氣:
[摘要]對于一個日訪問量達到百萬級的網(wǎng)站來說,速度很快就成為一個瓶頸。除了優(yōu)化內(nèi)容發(fā)布系統(tǒng)的應用本身外,如果能把不需要實時更新的動態(tài)頁面的輸出結果轉化成靜態(tài)網(wǎng)頁來發(fā)布,速度上的提升效果將是顯著的,因為一個動...
對于一個日訪問量達到百萬級的網(wǎng)站來說,速度很快就成為一個瓶頸。除了優(yōu)化內(nèi)容發(fā)布系統(tǒng)的應用本身外,如果能把不需要實時更新的動態(tài)頁面的輸出結果轉化成靜態(tài)網(wǎng)頁來發(fā)布,速度上的提升效果將是顯著的,因為一個動態(tài)頁面的速度往往會比靜態(tài)頁面慢2-10倍,而靜態(tài)網(wǎng)頁的內(nèi)容如果能被緩存在內(nèi)存里,訪問速度甚至會比原有動態(tài)網(wǎng)頁有2-3個數(shù)量級的提高。
動態(tài)緩存和靜態(tài)緩存的比較
基于反向代理加速的站點規(guī)劃
基于apache mod_proxy的反向代理加速實現(xiàn)
基于squid的反向代理加速實現(xiàn)
面向緩存的頁面設計
后臺的內(nèi)容管理系統(tǒng)的頁面輸出遵守可緩存的設計,這樣就可以把性能問題交給前臺的緩存服務器來解決了,從而大大簡化CMS系統(tǒng)本身的復雜程度。
靜態(tài)緩存和動態(tài)緩存的比較
靜態(tài)頁面的緩存可能有2種形式:其實主要區(qū)別就是CMS是否自己負責關聯(lián)內(nèi)容的緩存更新管理。
靜態(tài)緩存:是在新內(nèi)容發(fā)布的同時就立刻生成相應內(nèi)容的靜態(tài)頁面,比如:2003年3月22日,管理員通過后臺內(nèi)容管理界面錄入一篇文章后,就立刻生成http://www.chedong.com/tech/2003/03/22/001.html這個靜態(tài)頁面,并同步更新相關索引頁上的鏈接。
動態(tài)緩存:是在新內(nèi)容發(fā)布以后,并不預先生成相應的靜態(tài)頁面,直到對相應內(nèi)容發(fā)出請求時,如果前臺緩存服務器找不到相應緩存,就向后臺內(nèi)容管理服務器發(fā)出請求,后臺系統(tǒng)會生成相應內(nèi)容的靜態(tài)頁面,用戶第一次訪問頁面時可能會慢一點,但是以后就是直接訪問緩存了。
如果去ZDNet等國外網(wǎng)站會發(fā)現(xiàn)他們使用的基于Vignette內(nèi)容管理系統(tǒng)都有這樣的頁面名稱:0,22342566,300458.html。其實這里的0,22342566,300458就是用逗號分割開的多個參數(shù):
第一次訪問找不到頁面后,相當于會在服務器端產(chǎn)生一個doc_type= 0&doc_id=22342566&doc_template=300458的查詢,
而查詢結果會生成的緩存的靜態(tài)頁面: 0,22342566,300458.html
靜態(tài)緩存的缺點:
復雜的觸發(fā)更新機制:這兩種機制在內(nèi)容管理系統(tǒng)比較簡單的時候都是非常適用的。但對于一個關系比較復雜的網(wǎng)站來說,頁面之間的邏輯引用關系就成為一個非常非常復雜的問題。最典型的例子就是一條新聞要同時出現(xiàn)在新聞首頁和相關的3個新聞專題中,在靜態(tài)緩存模式中,每發(fā)一篇新文章,除了這篇新聞內(nèi)容本身的頁面外,還需要系統(tǒng)通過觸發(fā)器生成多個新的相關靜態(tài)頁面,這些相關邏輯的觸發(fā)也往往就會成為內(nèi)容管理系統(tǒng)中最復雜的部分之一。
舊內(nèi)容的批量更新: 通過靜態(tài)緩存發(fā)布的內(nèi)容,對于以前生成的靜態(tài)頁面的內(nèi)容很難修改,這樣用戶訪問舊頁面時,新的模板根本無法生效。
在動態(tài)緩存模式中,每個動態(tài)頁面只需要關心,而相關的其他頁面能自動更新,從而大大減少了設計相關頁面更新觸發(fā)器的需要。
以前做小型應用的時候也用過類似方式:應用首次訪問以后將數(shù)據(jù)庫的查詢結果在本地存成一個文件,下次請求時先檢查本地緩存目錄中是否有緩存文件,從而減少對后臺數(shù)據(jù)庫的訪問。雖然這樣做也能承載比較大的負載,但這樣的內(nèi)容管理和緩存管理一體的系統(tǒng)是很難分離的,而且數(shù)據(jù)完整性也不是很好保存,內(nèi)容更新時,應用需要把相應內(nèi)容的的緩存文件刪除。但是這樣的設計在緩存文件很多的時候往往還需要將緩存目錄做一定的分布,否則一個目錄下的文件節(jié)點超過3000,rm *都會出錯。
這時候,系統(tǒng)需要再次分工,把復雜的內(nèi)容管理系統(tǒng)分解成:內(nèi)容輸入和緩存這2個相對簡單的系統(tǒng)實現(xiàn)。
后臺:內(nèi)容管理系統(tǒng),專心的將內(nèi)容發(fā)布做好,比如:復雜的工作流管理,復雜的模板規(guī)則等……
前臺:頁面的緩存管理則可以使用緩存系統(tǒng)實現(xiàn)
所以分工后:內(nèi)容管理和緩存管理2者,無論哪一方面可選的余地都是非常大的:軟件(比如前臺80端口使用SQUID對后臺8080的內(nèi)容發(fā)布管理系統(tǒng)進行緩存),緩存硬件,甚至交給akamai這樣的專業(yè)服務商。
面向緩存的站點規(guī)劃
一個利用SQUID對多個站點進行做WEB加速http acceleration方案:
原先一個站點的規(guī)劃可能是這樣的:
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臺是為了冗余備份)
工作原理:
外部請求過來時,設置緩存根據(jù)配置文件進行轉向解析。這樣,服務器請求就可以轉發(fā)到我們指定的內(nèi)部地址上。
在處理多虛擬主機轉向方面:mod_proxy比squid要簡單一些:可以把不同服務轉向后后臺多個IP的不同端口上。
而squid只能通過禁用DNS解析,然后根據(jù)本地的/etc/hosts文件根據(jù)請求的域名進行地址轉發(fā),后臺多個服務器必須使用相同的端口。
使用反向代理加速,我們不僅可以得到性能上的提升,而且還能獲得額外的安全性和配置的靈活度:
配置靈活性提高:可以自己在內(nèi)部服務器上控制后臺服務器的DNS解析,當需要在服務器之間做遷移調(diào)整時,就不用大量修改外部DNS配置了,只需要修改內(nèi)部DNS實現(xiàn)服務的調(diào)整。
數(shù)據(jù)安全性增加:所有后臺服務器可以很方便的被保護在防火墻內(nèi)。
后臺應用設計復雜程度降低:原先為了效率常常需要建立專門的圖片服務器images.chedong.com和負載比較高的應用服務器 bbs.chedong.com分離,在反向代理加速模式中,所有前臺請求都通過緩存服務器:實際上就都是靜態(tài)頁面,這樣,應用設計時就不用考慮圖片和應用本身分離了,也大大降低了后臺內(nèi)容發(fā)布系統(tǒng)設計的復雜程度,由于數(shù)據(jù)和應用都存放在一起,也方便了文件系統(tǒng)的維護和管理。
基于Apache mod_proxy的反向代理緩存加速實現(xiàn)
Apache包含了mod_proxy模塊,可以用來實現(xiàn)代理服務器,針對后臺服務器的反向加速
安裝apache 1.3.x 編譯時:
--enable-shared=max --enable-module=most
注:Apache 2.x中mod_proxy已經(jīng)被分離成mod_proxy和mod_cache:同時mod_cache有基于文件和基于內(nèi)存的不同實現(xiàn)
創(chuàng)建/var/www/proxy,設置apache服務所用戶可寫
mod_proxy配置樣例:反相代理緩存+緩存
架設前臺的www.example.com反向代理后臺的www.backend.com的8080端口服務。
修改:httpd.conf
<VirtualHost *>
ServerName www.example.com
ServerAdmin admin@example.com
# 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的反向代理加速實現(xiàn)
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中:加入內(nèi)部的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---------------------------------
創(chuàng)建緩存目錄:
/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)
可緩存的動態(tài)頁面設計
什么樣的頁面能夠比較好的被緩存服務器緩存呢?如果返回內(nèi)容的HTTP HEADER中有"Last-Modified"和"Expires"相關聲明,比如:
Last-Modified: Wed, 14 May 2003 13:06:17 GMT
Expires: Fri, 16 Jun 2003 13:06:17 GMT
前端緩存服務器在期間會將生成的頁面緩存在本地:硬盤或者內(nèi)存中,直至上述頁面過期。
因此,一個可緩存的頁面:
頁面必須包含Last-Modified: 標記
一般純靜態(tài)頁面本身都會有Last-Modified信息,動態(tài)頁面需要通過函數(shù)強制加上,比如在PHP中:
// always modified now
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
必須有Expires或Cache-Control: max-age標記設置頁面的過期時間:
對于靜態(tài)頁面,通過apache的mod_expires根據(jù)頁面的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>
對于動態(tài)頁面,則可以直接通過寫入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標記,允許前臺
ASP應用的緩存改造 首先在公用的包含文件中(比如include.asp)加入以下公用函數(shù): <%
' 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)
%>
如何檢查目前站點頁面的可緩存性(Cacheablility)呢?可以參考以下2個站點上的工具:
http://www.ircache.net/cgi-bin/cacheability.py
附:SQUID性能測試試驗
phpMan.php是一個基于php的man page server,每個man page需要調(diào)用后臺的man命令和很多頁面格式化工具,系統(tǒng)負載比較高,提供了Cache Friendly的URL,以下是針對同樣的頁面的性能測試資料:
測試環(huán)境:Redhat 8 on Cyrix 266 / 192M Mem
測試程序:使用apache的ab(apache benchmark):
測試條件:請求50次,并發(fā)50個連接
測試項目:直接通過apache 1.3 (80端口) vs squid 2.5(8000端口:加速80端口)
測試1:無CACHE的80端口動態(tài)輸出:
ab -n 100 -c 10 http://www.chedong.com:81/phpMan.php/man/kill/1
This is ApacheBench, Version 1.3d <$Revision: 1.1 $> 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.1 $> 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個數(shù)量級的提高,因為SQUID是把緩存頁面放在內(nèi)存里的(因此幾乎沒有硬盤I/O操作)。
小節(jié):
大訪問量的網(wǎng)站應盡可能將動態(tài)網(wǎng)頁生成靜態(tài)頁面作為緩存發(fā)布,甚至對于搜索引擎這樣的動態(tài)應用來說,緩存機制也是非常非常重要的。
在動態(tài)頁面中利用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
相關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