ASP.NET應用程式的擴充策略

作 為 ASP.NET 效能顧問，我們接觸的項目通常都是已經出現問題的項目。在許多情況下，求助電話 都是在應用程式已經投產後才打來的。在開發人員那裡一切都正常的程式到了使用者那裡卻無法正常運行。 他們抱怨：網站太慢了。管理部門想知道為什麼在測試的時候沒有發現這一問題。開發部門卻無法重現問 題。於是有人說 ASP.NET 不能擴充。聽起來是不是很熟悉？

世界上一些最繁忙的 Web 網站都是運行在 ASP.NET 上。MySpace 就是一個很好的例子；實際上，它 是在多種不同的平台上都經過運行後才被遷移到 ASP.NET 上的。事實上，效能問題可能是隨著應用程式 的不斷擴充而顯現出來的，當出現這種情況時，您需要確定所發生的實際問題並找出解決該問題的最佳策 略。您將面臨的最大挑戰是建立一組測量標準，其中要涵蓋應用程式方方面面的效能。如果不將問題通盤 加以考慮，您就無法知道要將側重點放在哪一方面。

效能等式

2006 年 9 月， NetForecast 的 Peter Sevcik 和 Rebecca Wetzel 發表了一篇名為 "Field Guide to Application Delivery Systems" 的論文。該論文專門討論了如何改善廣域網路 (WAN) 應用程式的性 能，並包括了圖 1 所示的等式。此等式針對的是 WAN 的效能，但只需做少量修改便可用來衡量 Web 應 用程式的效能。修改後的等式如圖 2 所示，其中的各個元素在圖 3 中進行瞭解釋。

Figure 3 效能等式的元素

變數	定義
R	回應時間。從使用者請求頁面（通過單 擊連結等操作）到整個頁面全部呈現在使用者電腦中所需的總時間。通常以秒為測量單位。
負載	發送到瀏覽器的位元組總數，包括標記和所有資源（例如，CSS、JS 和 影像檔等）。
頻寬	與瀏覽器之間的傳輸率。這可能是不對稱的，如果給 定頁面是從多個源產生的，這可能表示多個速度。通常情況下，會加總取一平均值作為單一頻寬，單位為 位元組/秒。
AppTurns	給定頁面所需的資源檔數。這些資源檔包括 CSS、 JS、映像等，還包括瀏覽器在頁面顯示過程中檢索的任何其他檔案。在此等式中，HTML 頁面是通過在 AppTurns 運算式之前加上往返時間 (RTT) 單獨計算的。
RTT	往返所需的時 間，與傳輸的位元組無關。對於頁面本身，每個請求至少需要耗用一個 RTT。通常以毫秒為測量單位。
並發請求	瀏覽器同時發出的請求資源檔的請求數。預設情況下， Internet Explorer 執行兩個並發請求。此設定可以進行調整，但很少這樣做。
Cs	伺服器上的計算時間。這是運行代碼、從資料庫檢索資料以及合成要發 送到瀏覽器的響應所需的時間。測量單位為毫秒。
Cc	用戶端上的計算時間 。這是瀏覽器在螢幕上實際顯示 HTML、執行 JavaScript、實施 CSS 規則等所需的時間。

Figure 1 The Original Performance Equation

Figure 2 The Web Version of the Performance Equation