數據層性能
技巧 1 — 返回多個結果集
技巧 2 — 分頁的數據訪問
技巧 3 — 連接池
技巧 4 — ASP.NET 緩存 API
技巧 5 — 每請求緩存
技巧 6 — 后臺處理
技巧 7 — 頁輸出緩存和代理服務器
技巧 8 — 運行 IIS 6.0（只要用于內核緩存）
技巧 9 — 使用 Gzip 壓縮
技巧 10 — 服務器控件視圖狀態
小結
使用 ASP.NET 編寫 Web 應用程序的簡單程度令人不敢相信。正因為如此簡單，所以很多開發人員就不會花時間來設計其應用程序的結構，以獲得更好的性能了。在本文中，我將講述 10 個用于編寫高性能 Web 應用程序的技巧。但是我并不會將這些建議僅局限于 ASP.NET 應用程序，因為這些應用程序只是 Web 應用程序的一部分。本文不作為對 Web 應用程序進行性能調整的權威性指南 — 一整本書恐怕都無法輕松講清楚這個問題。請將本文視作一個很好的起點。
成為工作狂之前，我原來喜歡攀巖。在進行任何大型攀巖活動之前，我都會首先仔細查看指南中的路線，閱讀以前游客提出的建議。但是，無論指南怎么好，您都需要真正的攀巖體驗，然后才能嘗試一個特別具有挑戰性的攀登。與之相似，當您面臨修復性能問題或者運行一個高吞吐量站點的問題時，您只能學習如何編寫高性能 Web 應用程序。
我的個人體驗來自在 Microsoft 的 ASP.NET 部門作為基礎架構程序經理的經驗，在此期間我運行和管理 www.ASP.NET，幫助設計社區服務器的結構，社區服務器是幾個著名 ASP.NET 應用程序（組合到一個平臺的 ASP.NET Forums、.Text 和 nGallery）。我確信有些曾經幫助過我的技巧對您肯定也會有所幫助。
您應該考慮將應用程序分為幾個邏輯層。您可能聽說過 3 層（或者 n 層）物理體系結構一詞。這些通常都是規定好的體系結構方式，將功能在進程和/或硬件之間進行了物理分離。當系統需要擴大時，可以很輕松地添加更多的硬件。但是會出現一個與進程和機器跳躍相關的性能下降，因此應該避免。所以，如果可能的話，請盡量在同一個應用程序中一起運行 ASP.NET 頁及其相關組件。
因為代碼分離以及層之間的邊界，所以使用 Web 服務或遠程處理將會使得性能下降 20% 甚至更多。
數據層有點與眾不同，因為通常情況下，最好具有專用于數據庫的硬件。然而進程跳躍到數據庫的成本依然很高，因此數據層的性能是您在優化代碼時首先要考慮的問題。
在深入應用程序的性能修復問題之前，請首先確保對應用程序進行剖析，以便找出具體的問題所在。主要性能計數器（如表示執行垃圾回收所需時間百分比的計數器）對于找出應用程序在哪些位置花費了其主要時間也非常有用。然而花費時間的位置通常非常不直觀。
本文講述了兩種類型的性能改善：大型優化（如使用 ASP.NET 緩存），和進行自身重復的小型優化。這些小型優化有時特別有意思。您對代碼進行一點小小的更改，就會獲得很多很多時間。使用大型優化，您可能會看到整體性能的較大飛躍。而使用小型優化時，對于某個特定請求可能只會節省幾毫秒的時間，但是每天所有請求加起來，則可能會產生巨大的改善。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/