2009-11-18 19 views
2

我的作品中的建築師最近閱讀Yahoo!'s Exceptional Performance Best Practices指南,它指出對於JavaScript,CSS和圖像等頁面使用的資源使用遠期Expires標題。這個想法是你爲未來的這些資源設置一個Expires頭文件,這樣它們總是被瀏覽器緩存,當我們改變文件並因此需要瀏覽器再次請求資源而不是使用它的緩存時,改變文件名通過添加一個版本號。ASP.NET:合法的體系結構/ HttpModule的擔憂?

雖然沒有將它融入到我們的構建過程中,但他有另一個想法。我們會僞造它,而不是在每個版本中更改源文件和服務器磁盤上的文件名(授予,這將是單調乏味的),我們將僞造它。他的計劃是在所述資源上設置遠期到期,然後實施兩個HttpModules。

一個模塊會在我們的ASPX和HTML頁面出來之前攔截所有的Response流,查找資源鏈接,並查找作爲文件上次修改日期的版本參數。另一個HttpModule將處理所有資源請求,並簡單地忽略該地址的版本部分。這樣,瀏覽器每次在磁盤上更改時都會請求一個新的資源文件,而不必實際更改磁盤上文件的名稱。

有意義嗎?

我的問題涉及到重寫ASPX/HTML頁面響應流的模塊。他只是在<script><img>標記的「src」屬性以及<link>標記的「href」屬性上應用一堆Regex.Replace()。對於內容類型爲「text/html」的服務器上的每個請求都會發生這種情況。可能每分鐘數百或數千。

據我所知,HttpModules掛鉤到IIS管道中,但是這需要在IIS發送HTTP響應所需的時間內增加一個令人望而窒息的延遲。沒有?你怎麼看?

+0

我認爲如果你在構建過程中這樣做(實際上發佈過程會更好),算法將是相同的,唯一的區別是你只執行一次操作,而不是每次請求。 – 2009-11-18 00:12:10

回答

0

他擔心沒有在客戶端緩存的東西 - 顯然這取決於用戶羣如何配置瀏覽器;如果它是默認配置,那麼我懷疑你需要擔心嘗試第二次猜測客戶端緩存,這太難了,結果也不能保證,也不會幫助新用戶。就HTTP模塊而言 - 原則上我會說它們很好,但是如果你走這條軌道,你會希望它們變得快速而高效;這可能值得嘗試。不過,我不能說使用RegEx來做你想做的事情的恰當性。

如果你正在尋找高性能,我建議你(或你的建築師)做一些閱讀(我不認爲這是一個討厭的方式)。我最近學到了一些我認爲會有所幫助的東西 - 我可以解釋一下(也許你們已經知道了)。

瀏覽器在同一時間僅保持有限數量的同時連接對特定主機名開放。例如,IE6只會做6個連接來說明www.foo.net。

如果你從images.foo.net中調用你的圖片,你會馬上得到6個新的連接。 這個想法是把不同的內容類型分離成不同的主機名(css.foo.net,scripts.foo.net,ajaxcalls.foo.net),這樣你就可以確保瀏覽器真正代表你的工作。

+0

不同的主機名技巧也在同一個雅虎的卓越性能最佳實踐指南中找到,原來的海報鏈接,fyi! – Funka 2009-11-18 04:40:58

1

有幾件事情需要注意的:

  1. 如果這個想法是添加一個查詢字符串到靜態文件名來表示他們的版本,遺憾的是,也將阻止緩存內核模式HTTP驅動程序(http.sys)
  2. 基於一堆正則表達式掃描每個整個響應將會慢,慢,慢。這也可能是不可靠的,與難以預測的角落案件。

幾個備選方案:

  1. 使用控制適配器,以明確當前版本替換某些URL或路徑。這允許您專注於圖像,CSS等。
  2. 當您使用靜態文件版本時更改文件夾名稱而不是文件名稱
  3. 考慮使用ASP.NET皮膚來幫助集中文件名。這將有助於簡化維護。

如果有幫助,我會在我的書(Ultra-Fast ASP.NET)中介紹這個主題,包括代碼示例。

0

http://code.google.com/p/talifun-web

StaticFileHandler - 在一個可緩存的,可恢復的方式提供靜態文件。 CrusherModule - 以可緩存的方式提供壓縮的版本JS和CSS。

你不完全獲得內核模式緩存速度,但從HttpRuntime.Cache服務有其優點。內核模式緩存無法緩存部分響應,並且您沒有對緩存進行細粒度控制。實現最重要的是一致的etag頭和expires頭。這比其他任何事情都會改善您的網站性能。

減少提供的文件數可能是提高網站速度的最佳方法之一。 CrusherModule將您網站上的所有CSS組合到一個文件中,並將所有js合併到另一個文件中。

內存很便宜,硬盤很慢,所以使用它!