作 為 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
