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