使用 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 緩存），和進行自身重復的小型優化。這些小型優化有時特別有意思。您對代碼進行一點小小的更改，就會獲得很多很多時間。使用大型優化，您可能會看到整體性能的較大飛躍。而使用小型優化時，對于某個特定請求可能只會節省幾毫秒的時間，但是每天所有請求加起來，則可能會產生巨大的改善。 數據層性能
談到應用程序的性能調整，有一個試紙性的測試可用來對工作進行優先級劃分：代碼是否訪問數據庫？如果是，頻率是怎樣的？請注意，這一相同測試也可應用于使用 Web 服務或遠程處理的代碼，但是本文對這些內容未做講述。 如果某個特定的代碼路徑中必需進行數據庫請求，并且您認為要首先優化其他領域（如字符串操作），則請停止，然后執行這個試紙性測試。如果您的性能問題不是非常嚴重的話，最好花一些時間來優化一下與數據庫、返回的數據量、進出數據庫的往返頻率相關的花費時間。 了解這些常規信息之后，我們來看一下可能會有助于提高應用程序性能的十個技巧。首先，我要講述可能會引起最大改觀的更改。 技巧 1 — 返回多個結果集