與其他許多人一樣，我眼下也滯留在歐洲，等待飛回美國的航班。近期的火山噴發(fā)不僅影響了歐洲大陸的航班，還影響了全球各地眾多機場、航空公司和旅行社的網(wǎng)站。想在周日查看航班狀況？幾乎門都沒有！德國最大機場：法蘭克福機場的網(wǎng)站根本就訪問不了。這也難怪我會產(chǎn)生這樣的想法：他們的網(wǎng)頁恐怕遇到了眾多萬分沮喪的旅客提出的成千上萬的額外頁面請求。今天已是周二了，網(wǎng)站的響應時間恢復到了“基本上可以接受”的水平。就跟我之前分析過vancouver2010、utah.travel.com或masters.com等其他網(wǎng)站那樣，這回分析一下法蘭克福機場的網(wǎng)站。
現(xiàn)狀：太多的資源，緩存方面設(shè)置錯誤
使用免費性能分析工具dynaTrace AJAX Edition，瀏覽至http://www.frankfurt-airport.com，為我顯示了該主頁上的情況。Resource Graph（資源圖）顯示了JavaScript、CSS和圖像等文件的數(shù)量。在主頁上，我們看到有97個圖像、40個JavaScript文件和22個樣式表文件。我之前瀏覽過這個主頁——這就是為什么其中一些資源是從緩存顯示的。不過我們稍后會看到，目前的緩存設(shè)置仍要求我的瀏覽器發(fā)送請求。
網(wǎng)站上有太多的資源（97個圖像、40個JavaScript文件和22個CSS文件等）
繼續(xù)往下瀏覽至TimeLine View（時間線視圖），即可顯示這些資源是從哪里下載的，對頁面裝入時間有怎樣的影響。與許多類似的網(wǎng)站一樣，這些內(nèi)容來自許多不同的域。在這里，我們看到28個域分發(fā)廣告或標題廣告，或者提供Web用戶跟蹤等服務。我們發(fā)現(xiàn)，觸發(fā)onLoad事件需要花11秒——這時候，所有的初始內(nèi)容（HTML+引用的對象）已下載完畢。下載時間大部分花在了由www.frankfurt-airport.com提供內(nèi)容。大多數(shù)圖像、JavaScript和CSS等文件是從這個域下載的。
由于物理網(wǎng)絡(luò)連接方面的限制，瀏覽器只使用2條物理連接來下載這些資源，導致從這個域純粹下載的時間約為7秒。使用多個域——這種方法名為域名碎片（Domain Sharding），讓瀏覽器可以使用更多的物理連接來并行下載這些資源。這最終縮短了頁面裝入時間。值得一提的另外一點是下載的文件數(shù)量。直到onLoad事件被觸發(fā)，從主域下載了125個資源。通過合并JavaScript和CSS文件，并且拼合圖像文件（可能的話），可以大幅減少這個數(shù)字，因而減少了往返次數(shù)，因而同樣縮短了頁面裝入時間。
內(nèi)容來自28個Web域。大多數(shù)圖像是從frankfurt-airport.com這個域提供的，減慢了頁面裝入速度。
我的下一步是更仔細地分析緩存。瀏覽器能夠緩存一些內(nèi)容，比如靜態(tài)圖像、樣式表或JavaScript文件。對不經(jīng)常變化的內(nèi)容來說，緩存機制再好不過了。為了驗證緩存設(shè)置正確，我第二次瀏覽至主頁，記錄下另一個會話。如果緩存方面配置正確，我的瀏覽器應該不會從服務器獲取某些資源，而是徑直從本地瀏覽器的緩存獲取。Summary View（摘要視圖）看起來很好——大多數(shù)資源似乎實際上是從緩存獲取的：
大多數(shù)圖像、CSS和JavaScript文件現(xiàn)在從瀏覽器的緩存獲取。
看起來不錯，但等一下。不要被表象蒙蔽了。我們?nèi)钥吹絊erver Transfer（服務器傳輸）時間方面的數(shù)值非常高。憑我的經(jīng)驗，這意味著，盡管內(nèi)容是從緩存獲取的，但是瀏覽器將HTTP請求發(fā)送至服務器，以便每一個資源“詢問”內(nèi)容自上一次下載資源以來是否經(jīng)過了改動（IF-MODIFIED-SINCE）。如果我?guī)讉€星期或幾個月沒有訪問該網(wǎng)站，這沒什么；但是如果上一次頁面訪問發(fā)生在僅僅幾分鐘之前，就不行了。
如果更仔細地看一下Network Requests（網(wǎng)絡(luò)請求）視圖，就會發(fā)現(xiàn)問題之所在。Expires頭實際上被設(shè)置為“過去時間”。我記錄的訪問會話是2010年4月20日格林威治標準時間9點38分。Expires頭被設(shè)置為4月19日——也就是前一天。這就是為什么我的瀏覽器不得不將HTTP請求發(fā)送至服務器，以便每一個“緩存”的元素檢查服務器上面有沒有更新版的資源。Server（服務器）這一列顯示多少時間花在了服務器上的每個請求，確定資源有沒有發(fā)生變化。Wait（等待）這一列告訴我們，每個請求得等待多久才被處理（這再次歸因于物理網(wǎng)絡(luò)連接方面的限制——每個域只有2條物理連接可用，其他所有請求不得不等待）。
過去時間的Expires頭使得瀏覽器為每個緩存的資源發(fā)送IF-MODIFIED-SINCE請求。
Network（網(wǎng)絡(luò)）視圖顯示了幾乎所有的HTTP頭。由于IE中dynaTrace AJAX插件具有的性質(zhì)，我們沒有獲得所有的HTTP頭，但是我們獲得了最值得關(guān)注的HTTP頭。我們的用戶已經(jīng)要求社區(qū)愿望清單（Community Wish List）上有這項特性。眼下我提議使用網(wǎng)絡(luò)嗅探器或代理，比如MS Fiddler、HTTP Watch或Charles，以免你嫌AJAX Edition提供的信息還不夠詳細。
如何提升性能？
從理論上來說，為諸如此類的網(wǎng)站提升相當簡單。我之所以講從理論上來說如此，是因為一些提議的變化需要在Web服務器或Web部署環(huán)境上作一些工作或變化。下面列出了一系列提議的變化和估計的性能提升：
•使用HTTP 1.1或至少使用Connection: Keep-Alive：Web服務器使用HTTP 1.0，迫使服務器在每次請求之后關(guān)閉物理連接。使用Connection Keep-Alive可以避免不必要的重新連接工作。
◦估計的性能提升：縮短100至200毫秒（查看網(wǎng)絡(luò)視圖中的Connect Column）
•添加有效期非常長久的Expires頭：對于不常變化的那些元素來說，應使用有效期非常長久的Expires頭。
◦估計為返回用戶帶來的性能提升：縮短4-6秒（具體取決于實際上能長久地緩存多少個對象）。
•合并CSS：把所有22個CSS文件合并成一個CSS文件，可以消除Wait Time（等待時間），并且因減少了HTTP往返次數(shù)，因而縮短了Server Time（服務器時間）和Transfer Time（傳輸時間）。
◦估計的性能提升：等待時間縮短1.3秒，服務器時間和傳輸時間縮短1-2秒（假設(shè)我們能合并CSS文件）
•合并JavaScript：21個JavaScript文件來自主域。合并這些文件可消除等待時間，并因減少了HTTP往返次數(shù)而縮短了服務器時間和傳輸時間。
◦估計的性能提升：縮短300-500毫秒
•域名碎片：把由主頁面提供的75個圖像分散到另外2個圖像子域上，讓瀏覽器可以并行下載4個圖像。這還讓來自主頁的其他內(nèi)容（比如AJAX請求）不必等待圖像下載，就可以下載。
◦估計的性能提升：縮短2-3秒
結(jié)論
常常被忽視的小地方（比如錯誤的Expires頭）對網(wǎng)站性能大有影響。如果法蘭克福機場的網(wǎng)站能夠遵循來自谷歌或雅虎的一些最佳實踐，或者是我們在dynaTrace博客上介紹的那些最佳實踐，我相當確信許多游客能夠在周日訪問其網(wǎng)站。
原文：How better Caching helps Frankfurt’s Airport Website to handle additional load caused by the Volcano
譯文鏈接：http://developer.51cto.com/art/201209/357025.htm
