<form id="hz9zz"></form>
  • <form id="hz9zz"></form>

      <nobr id="hz9zz"></nobr>

      <form id="hz9zz"></form>

    1. 明輝手游網中心:是一個免費提供流行視頻軟件教程、在線學習分享的學習平臺!

      基于反向代理的Web緩存加速——可緩存的CMS系統設計

      [摘要]對于一個日訪問量達到百萬級的網站來說,速度很快就成為一個瓶頸。除了優化內容發布系統的應用本身外,如果能把不需要實時更新的動態頁面的輸出結果轉化成靜態網頁來發布,速度上的提升效果將是顯著的,因為一個動...
      對于一個日訪問量達到百萬級的網站來說,速度很快就成為一個瓶頸。除了優化內容發布系統的應用本身外,如果能把不需要實時更新的動態頁面的輸出結果轉化成靜態網頁來發布,速度上的提升效果將是顯著的,因為一個動態頁面的速度往往會比靜態頁面慢2-10倍,而靜態網頁的內容如果能被緩存在內存里,訪問速度甚至會比原有動態網頁有2-3個數量級的提高。


      動態緩存和靜態緩存的比較
      基于反向代理加速的站點規劃

      基于apache mod_proxy的反向代理加速實現
      基于squid的反向代理加速實現
      面向緩存的頁面設計
      后臺的內容管理系統的頁面輸出遵守可緩存的設計,這樣就可以把性能問題交給前臺的緩存服務器來解決了,從而大大簡化CMS系統本身的復雜程度。



      靜態緩存和動態緩存的比較

      靜態頁面的緩存可能有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個相對簡單的系統實現。


      后臺:內容管理系統,專心的將內容發布做好,比如:復雜的工作流管理,復雜的模板規則等……
      前臺:頁面的緩存管理則可以使用緩存系統實現


      所以分工后:內容管理和緩存管理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臺是為了冗余備份)
      工作原理:
      外部請求過來時,設置緩存根據配置文件進行轉向解析。這樣,服務器請求就可以轉發到我們指定的內部地址上。

      在處理多虛擬主機轉向方面: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 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的反向代理加速實現

      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標記,允許前臺
      ASP應用的緩存改造 首先在公用的包含文件中(比如include.asp)加入以下公用函數: <%
      ' 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需要調用后臺的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.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個數量級的提高,因為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


      相關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


      日韩精品一区二区三区高清