導讀：
1 前言
效能最佳化的主要目標是提高“並發使用者數量”，“輸送量”，“可靠性”這樣幾個指標。
本質上說，效能最佳化的工作應該是多方面的，要做到“點面結合、由表及裡”。比如：從代價的角度來考慮，應盡量做到改動量小，易實施；從使用者角度看，應做到快速響應或快速提示；從軟體結構的角度看，又要兼顧到系統結構的合理性和可擴充性。由此不難發現，在嘗試一些改進方法時往往很難做到面面俱到。
舉一個簡單的例子：
在一個商務邏輯類中，我們封裝了一些處理方法，其中有一個方法的功能是尋找一個節點ID在XML檔案是否已經存在。那我們自然會想到寫兩個方法：
XmlDocument LoadXML(string strFileID) //載入XML
bool CheckIDExisit(string strFileID,string strID) //判斷節點是否存在
而且，載入XML的方法在其他地方還可以重用；表面上看，這段代碼的結構和功能都沒有問題。可是在運行時，如果你的邏輯中直接或間接調用了LoadXML多次的話，你會發現程式很慢。原因就在於載入XML檔案是個耗時動作，解決的方法很簡單，我們再提供幾個方法即可：
bool CheckIDExisitByXml (string strXml,string strID) //判斷節點是否存在
或 bool CheckIDExisitByXml (XmlDocument objXml,string strID) //判斷節點是否存在
這樣，我們就可以通過“一次載入”實現多次借用，效率明顯提升。所以，在軟體結構設計時就應將可重用“珍貴”資料來源的因素考慮進來。(這裡的“珍貴”資料來源是指那些經過複雜處理或長時間計算才得到的各種對象或記錄集)。
效能最佳化的工作又應是長期的，因為我們的工作始終是建立在OS,Web Server, DB Server, Complier & Program Language等等的基礎上的。如果你熟悉.NET, JAVA,IIS, J2EE,你就會發現有些功能或API這個平台提供了，另一個卻沒有；所以更多時候我們需要過渡的解決方案，等到新版本出來時，我們可能就會拋棄過渡方案直接配置或更簡便的實現一些功能。[...]
2 需求篇
效能最佳化的第一步是看看需求是否合理，這是對項目本身的一次回檢。某種意義上說，是一種逃避原則。但如果從軟體工程的角度來說這是必須的，因為客戶的需求是無止境的，而任何軟體都是有生命期的，OS都是這樣何況應用軟體。我們總是希望使用者顯示與商務邏輯分開的越遠越好，卻忽略了一個基本問題：兩者終歸要銜接起來，如何定義兩者之間的I/O關係，讓它們能有效相互配合并最終讓使用者滿意是非常重要的。
所以，在效能最佳化時回檢需求就是要把使用者互動定義好，使之更科學化。從業界發展動態看，現在已經有專門的人在研究使用者互動，這就像傳統行業裡的所謂“工業設計”一樣，正越來越被重視！
在回檢需求時往往會“修改需求”，這時應該結合“需求定義人員”和“開發人員”兩方面的意見，因為各方角度不同，一定要取長補短。
3 互動響應篇
前面提到效能最佳化時可按“由表及裡”的順序，這主要有兩方面的考慮：
第一， 這是使用者直接看到的東西，見效快；
第二， 改動難度比改動核心要小。
基於B/S結構的應用程式有前台(使用者)與後台(Server)互動的問題，所以互動響應過程實際包括“後台計算”與“載入到用戶端”兩個過程。那麼很顯然，我們如果盡量減少需要下載到用戶端的資料量，會減小回應時間。
根據測試，我們發現將4萬條記錄綁定到Grid的時間在35s左右，而實際上我們不會在頁面一下子顯示這麼多條記錄，使用者也不可能一下子瀏覽這麼多記錄。通常我們使用分頁的方式，而所謂的分頁只不過是重新綁定一下資料。所以，如果如果我們每次只綁定所請求的那一頁則到用戶端的資料量會陡降。這就是我們提出的“計算全部資料，載入局部資料”的思路（如）。
我們再從使用者的角度看另外兩個問題，曾使用ASP應用程式的人會發現ASP.NET應用程式使用時重新整理頻率很高，一個小小的動作都要提交到服務端去處理。從軟體設計的角度看，我們覺得很合理，因為沒有耦合且邏輯可重用。可是“魚與熊掌不可兼得”，我們還是應該採取折中的手法。回到我們的系統中來，我們發現多數頁面在對於使用較頻繁的“增-刪-改”操作時，都是每一次操作都從資料庫重新讀，重新綁定。如此頻繁的重新整理，使用者不會很認可，同時如果資料量大也會影響互動時間。
實際上，如果資料是顯示在Grid中，那麼刪除和修改時根本不需要重新Load, 直接用控制項本身的方法就可以了，雖然也會提交但與重新綁定還是有明顯區別的，速度也快得多！對於TreeView則“增-刪-改”都不需要重新Load，因為它不需要分頁。
另一個問題是對於複雜並可能耗時的計算過程，使用者雖可理解，但還是應該給出提示或進度條。這並不屬於效能最佳化的範疇，但卻是重要的UI規範，建議納入測試要求。關於進度條的顯示有兩種方式：
1 前台顯示等待或完成進度，幕後處理完了，前台進度條關閉，處理結果顯示；
2 提交任務到後台後，轉到一個等待頁面，等後台完成後轉到確認頁面。這種方式通常基於XmlHttpRequest[13]技術，在後台建立單獨的計算線程，其優點是可以避免後台過於繁忙導致第一種顯示方式中用戶端長時間沒有反映，連進度條都不動了。
4 部署篇
部署其實是一個很大的概念，涵蓋了軟體和硬體。這裡我們暫將系統部署結構、軟體佈建、硬體設定都納為部署範圍。關於怎樣去部署一個軟體系統這裡就不贅述了，僅將一些具體做法列舉出來。
4.1 ASP.NET
在有大資料量傳輸時，經常會遇到“out of memory”的異常。這時可調節machine.config檔案中processModel子項中的memoryLimit 屬性的值，使得.NET可以利用更多的記憶體。
4.2 其他
4.2.1最佳化配置Server &IIS
4.2.1.1擴大IIS快取
伺服器保留了一部分記憶體空間用作IIS快取，為將來的請求儲存物件，這樣IIS就可從快取中檢索對象而不用從硬碟中檢索。調整IIS快取的容量需要修改註冊表，表項如下：
HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/InetInfo/Parameters/MemoryCacheSize
=0x 1E84800（類型為REG_DWORD，using hexadecimal notation.）
也可設為十進位，範圍0-4GB,預設值為3072000（3MB）。一般來說此值最小應設為伺服器記憶體的10%。
IIS通過快取系統控制代碼、目錄列表以及其他常用資料的值來提高系統的效能。這個參數指明了分配給快取的記憶體大小。如果該值為0，那就意味著“不進行任何快取”。在這種情況下系統的效能可能會降低。如果你的伺服器網路通訊繁忙，並且有足夠的記憶體空間，可以考慮增大該值。必須注意的是修改註冊表後，需要重新啟動才能使新值生效。
4.2.1.2調整IIS佔用CPU時間
伺服器的CPU處理器能力總是有限的。哪一個應用程式佔用處理器的時間最長，誰的效能就能得到最大的提高。
（1）在NT的控制台中，雙擊系統表徵圖。
（2）單擊效能標籤。
（3）在應用程式效能下將遊標拖到None的位置，這樣就可以使所有正在啟動並執行服務，包括IIS，使用處理器的時間達到最大值。
(4)選擇最大化網路應用程式的總處理能力。然後單擊“OK。”
4.2.1.3協議及相關最佳化
（1）為了提高效能和節約資源，應該只運行需要的協議。
（2）應該將IIS伺服器，設定為獨立的伺服器，不要讓伺服器去承受網域控制站要求的額外負荷。
（3）可以把NT伺服器的頁分頁檔分布到多個物理磁碟上，注意是多個“物理磁碟”，分布在多個分區上是無效的。另外，不要將頁分頁檔放在與Windows NT引導區相同的分區中。
（4）使用磁碟鏡像或磁碟帶區集可以提高磁碟的讀取效能。
（5）關於日誌的記錄，應該採用檔案記錄而不是記錄到ODBC資料來源。此外，還可以在記錄期間增加用來記錄日誌的記憶體緩衝區的容量來減少磁碟的活動。該緩衝區的預設容量值為64KB。
（6）最好把所有的資料都儲存在一個單獨的分區裡。然後定期運行磁碟磁碟重組程式以保證在儲存Web伺服器資料的分區中沒有片段。使用NTFS有助於減少片段。
（7）雖然SSL可以提供相當可靠的加密傳輸。但是所需的額外開銷會導致IIS伺服器速度下降，尤其是在處理大型檔案的時候。所以應該只對確實需要保護的目錄進行SSL加密。
4.2.1.4 調整失效時間
HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/InetInfo/Parameters/ObjectCacheTTL=0x8CA0.
4.2.1.5 調整最大線程數
HKEY_LOCAL_MACHINE/SYSTEM/ CurrentControlSet/Services/w3SVC/ASP/Parameters，增加ProcessorThreadMax，減小這個值，看看效能的變化；或者增大這個值。)
4.2.1.6 註冊表中的其他可最佳化項
以“HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/InetInfo/Parameters/”為父節點；
CacheSecurityDescriptor Indicates whether security descriptors are cached for file objects. A value of 1 enables this feature. A value of 0 disables this feature. When enabled (the default setting), security descriptors for files are saved when caching a file object. As long as the file is cached, IIS will not need to re-access the file to determine access rights for new users. This value is most useful for sites that authenticate users and not useful for sites that allow anonymous access.
CheckCertRevocation Indicates whether IIS checks to see if a client certificate is revoked. If you issue your own certificates and make local certificate checks, you might want to enable this feature. Otherwise, the feature should be disabled, which is the default. A value of 1 enables this feature.
DisableMemoryCache Indicates whether IIS memory caching is enabled or disabled. By default, memory caching is enabled (meaning this value is set to 0). Disable memory caching only for testing or development purposes.
ListenBackLog Specifies the maximum number of active connections that IIS maintains in the connection queue. The default value is 15 and the range of acceptable values is from 1 to 250.
MaxCachedFileSize Determines the maximum size of a file that can be placed in the file cache. IIS will not cache files that are larger than this value. The default value is 262,144 bytes (256 KB).
MaxConcurrency Specifies how many threads per processor should be allowed to run simultaneously if there is a pending input/output (I/O) operation. The default value (0) allows IIS to control the number of threads per processor. You can also set a specific value.
MaxPoolThreads Sets the number of pool threads to create per processor. Each pool thread watches for a network request for a CGI application and processes it. This value does not control threads that are used by ISAPI applications. By default, the value is set to 4. On a single processor system, this means that only four CGI applications could run simultaneously.
MemCacheSize Sets the maximum amount of memory that IIS will use for its file cache. If IIS does not need this much memory, it will be left for other applications to use. By default, IIS uses 50 percent of the available memory. The valid range is from 0 megabytes to the total amount of physical memory available in megabytes.
ObjectCacheTTL Sets the length of time(in milliseconds) that objects are held in memory. If the object hasn't been used in this interval, it is removed from memory. The default value is 30 seconds (300,000 milliseconds).
PoolThreadLimit Sets the maximum number of pool threads that can be created on the server. This limit is for all IIS threads. The default value is twice the size of physical memory in megabytes.
4.2.1.7禁用不必要的服務:
禁用專用 Web 服務器不需要的 Windows 2000服務。方法是：單擊開始，依次指向程式、管理工具，然後單擊電腦管理。在“電腦管理（本地）”下，展開“服務和應用程式”，然後單擊服務。當前所運行服務的狀態 列中顯示已啟動 。以下服務是專用 Web 服務器上不需要的：
警報器
剪貼簿
電腦瀏覽器
DHCP 用戶端
DHCP 伺服器
傳真服務
檔案複製
紅外線監視器
網際網路連線共用
信使
NetMeeting 遠端桌面共用
網路 DDE
網路 DDE DSDM
NWLink NetBIOS
NWLink IPX/SPX
後台列印程式
TCP/IP NetBIOS 支援服務
電話
Telnet
不斷電供應系統
================================================
記下與要停止的服務有依存關係的那些服務。方法是：
雙擊所需的服務。例如，雙擊信使。
單擊依存關係 選項卡。
在“服務名 依賴這些服務”列表中（其中，服務名是所選服務的名稱），記下該服務依賴的那些服務。
在“這些服務依賴服務名”列表中，記下沒有該服務就無法啟動的那些服務。
單擊確定。
禁用所需的服務。方法是：
按右鍵要禁用的服務，然後在出現的捷徑功能表上單擊屬性 。
在“啟動類型”列表中，單擊禁用。
如果要立即停止服務，請單擊停止。如果顯示停止其他服務 對話方塊，依賴於該服務的其他服務也將被停止。請記下受影響的服務，然後單擊是。
單擊確定。該服務的啟動類型 列中會顯示禁用 。
重複執行第 4 步，禁用其他不必要的服務。
備忘：禁用每個服務之後，應測試 Web 服務器電腦是否運行正常。這樣就最大程度地減少了禁用可能需要的服務而帶來的影響。
備忘：如果 IIS 伺服器是 Windows 2000 域成員，則必需 TCP/IP 支援服務，以便將組策略正確地應用到電腦中。
4.2.1.8 最大化網路應用程式資料輸送量
在工作記憶體中運行IIS 5.0 進程可分頁代碼。方法是：
在案頭上按右鍵網路位置，然後在出現的捷徑功能表中單擊屬性 。
按右鍵所需的本地串連 表徵圖，然後在出現的捷徑功能表中單擊屬性 。
在“此串連使用下列選定的組件”列表中，單擊“Microsoft 網路的檔案和印表機共用”（但不要清除其複選框），然後單擊屬性。
單擊“最大化網路應用程式資料輸送量”，然後單擊確定 兩次
4.2.1.9最佳化後台服務的效能
IIS 5.0 進程 (Inetinfo.exe) 作為後台服務運行。要提高後台服務的效能，請按以下步驟操作：
單擊開始，指向設定，然後單擊控制台。
在“控制台”中，雙擊系統。
單擊進階 選項卡，然後單擊效能選項。
在“應用程式響應”下，單擊“後台服務”，然後單擊確定 兩次。
退出“控制台”。
4.2.1.10 最小化 IIS 5.0 日誌記錄
禁止對不需要的 Web 網站、虛擬目錄或檔案及檔案夾進行日誌記錄。方法是：
單擊開始，依次指向程式、管理工具，然後單擊網際網路服務管理員。
展開“*伺服器名”，其中 伺服器名 是 Web 服務器的名稱。
找到所需的項，然後用按右鍵該項。在出現的捷徑功能表上，單擊屬性。例如，按右鍵預設 Web 網站，然後在出現的捷徑功能表上單擊屬性 。
執行下列操作之一：
如果選擇 Web 網站，則單擊主目錄 選項卡。
- 或 -
如果選擇虛擬目錄，則單擊虛擬目錄 選項卡。
- 或 -
如果選擇實際目錄，則單擊目錄 選項卡。
單擊“日誌訪問”複選框，將其清除，然後單擊確定。
要禁止整個 Web 網站的日誌記錄，請單擊Web 網站 選項卡，單擊啟用日誌記錄 複選框，將其清除，然後單擊確定。
退出“Internet 資訊服務”嵌入式管理單元。
4.2.1.11啟用頻寬節流設定
限制各 Web 網站可用的網路頻寬。方法是：
啟動“網際網路服務管理員”。
展開“*伺服器名”，其中伺服器名 是 Web 服務器的名稱。
按右鍵所需的 Web 網站（例如，預設 Web 網站），然後在出現的捷徑功能表上單擊屬性 。
單擊效能 選項卡，然後單擊“啟用頻寬節流設定”複選框，將其選中。
在“最大網路使用”框中，鍵入所需的值，然後單擊確定。
退出“Internet 資訊服務”嵌入式管理單元。
4.2.1.12 限制處理器使用
限制 Web 網站對處理器的佔用量。方法是：
啟動“網際網路服務管理員”。
展開“*伺服器名”，其中伺服器名 是 Web 服務器的名稱。
按右鍵所需的 Web 網站（例如，預設 Web 網站），然後在出現的捷徑功能表上單擊屬性 。
單擊效能 選項卡，然後單擊“啟用進程限制”複選框，將其選中。
在“最大程度使用 CPU”框中，鍵入所需的值。
單擊“強制性限制”複選框，將其選中，然後單擊確定。
備忘：如果不啟用強制性限制 選項，則不會強制執行“最大程度使用 CPU”的限制。在 Web 網站超過其允許的 CPU 使用限制時，即會在“事件記錄”中寫入事件。
退出“Internet 資訊服務”嵌入式管理單元。
4.2.1.13限制 Web 網站串連
限制各 Web 網站可用的串連數量。方法是：
啟動“網際網路服務管理員”。
展開“*伺服器名”，其中伺服器名 是 Web 服務器的名稱。
按右鍵所需的 Web 網站（例如，預設 Web 網站），然後在出現的捷徑功能表上單擊屬性 。
在串連下，單擊限於。
在“串連”框中，鍵入要允許的串連數量。
備忘：串連的每個用戶端大約同時使用四個串連。例如，將串連數限制在 200 大約允許 50 名使用者訪問 Web 網站。
單擊確定，然後退出“Internet 資訊服務”嵌入式管理單元。
4. 2.1.14 使用“保持 HTTP 串連”
預設情況下，能夠使用“保持 HTTP 串連”。要驗證是否啟用了“保持 HTTP 串連”，請按以下步驟操作：
啟動“網際網路服務管理員”。
展開“*伺服器名”，其中伺服器名 是 Web 服務器的名稱。
按右鍵所需的 Web 網站（例如，預設 Web 網站），然後在出現的捷徑功能表上單擊屬性 。
在串連下，確認“已啟用保持 HTTP 串連”複選框已被選中，然後單擊確定。
退出“Internet 資訊服務”嵌入式管理單元。
4.2.2 最佳化配置DBServer
4.2.2.1 SQLServer
記憶體是影響Microsoft SQL Server系統效能的一個重要因素。
SQL Server資料庫安裝時將為具有32MB實體記憶體的機器預設配置16MB可用記憶體，16MB實體記憶體的機器預設配置4MB可用記憶體。應在 Microsoft SQL Server資料庫安裝後進行記憶體選項(Memory)設定。為了確定SQL Server系統最適宜的記憶體需求，可以從總的實體記憶體中減去Windows 2000 Server需要的記憶體以及其它一些記憶體需求後綜合確定。
以下是SQL Server記憶體選項(Memory)設定方法
(1)從Microsoft SQL Server程式集中啟動SQL Enterprise Manager；
(2)從Server Manager視窗中選擇“Server”菜單選項；
(3)在“Server”菜單中選擇“Configurations”選項；
(4)在“Server Configuration”對話方塊中選擇”Configuration”標籤，
(5)選中“Memory”項目，在“Current”欄填入新值；
(6)停止並重新啟動SQLServer服務，使設定生效。
合理擴充虛擬記憶體、增大SQL Server可用記憶體
當SQL Server系統確實需要擴大可用記憶體時，應在磁碟空間充足的情況下擴充供虛擬
記憶體，並相應增大 SQL Server可用記憶體。具體做法是，系統管理員首先擴充伺服器的虛擬記憶體，然後再參考上表增大SQL Server可用記憶體，關鍵是要根據系統的負載情況綜合決定是否擴充。
使用tempinRAM
SQL Server使用tempdb臨時資料庫作為一些查詢串連操作時排序或建立暫存資料表的工作
空間。將tempdb建立在RAM中可以使系統操作效能有較大提高，而且因為tempdb在每次重啟動伺服器時都重建，這樣即使有非正常的關閉也是較為安全的，例如停電故障。要將tempdb建立在RAM中，可以使用sp_configure進行設定，具體用法請參閱有關資料。
由於tempdbinRAM使用的記憶體是由系統從記憶體體單獨分配的，與SQL Server的記憶體選
項設定的可用記憶體池是分開的，使用tempdbin RAM將減少整個系統的可用記憶體，應根據SQL Server和伺服器運行情況進行配置，否則就可能適得其反，影響系統效能。另外，適當增加tempdb資料庫空間，即使不使用tempdbin RAM，也可以提高資料庫的運行速度。
注意事項：在生產環境中SQL Server不要設定小於32MB記憶體，而且資料庫伺服器上盡量擴充供虛擬記憶體、增大SQL Server可用記憶體，應考慮實體記憶體使用狀況和磁碟空間；在可能的情況下，要為系統留有部分額外的記憶體，這樣在伺服器上開啟一個服務或添加一個進程且不改變SQL Server記憶體配置時，不致於使NT伺服器的運行速度受到影響(變得很慢)，一般認為最小為2MB最大為20MB。
4.2.3硬體提升
4.2.3.1 CPU/記憶體
如果測試確定存在處理器問題，您的第一個選擇當然就是將處理器升級或切換到多處理器電腦。如果確定要升級處理器，應確保它有最大的 L2 緩衝，IIS 將因此而受益，因為它的許多指令路徑都包括多個組件，它們在快取中運行時速度會大大加快。
電腦名稱/記憶體/可用記憶體 - 該計數器跟蹤系統中的可用記憶體總量。作業系統嘗試將該值保持在 4 MB 以上。為了達到最佳效能，該值最好為記憶體總量的 5%。
4.2.3.2 硬碟
不要將記錄檔與 Web 頁儲存在同一個硬碟上。這將阻止硬碟日誌記錄線程幹預檢索 Web 頁的線程。
最佳化 Web 頁儲存。網站上的所有相關 Web 頁應該儲存在同一個邏輯分區，這樣可以提高檔案系統快取的效能。同時，Web 頁檔案不應有任何片段，這樣可以極大地加快讀取單個檔案的速度。
如果使用Ultra2的SCSI硬碟，可以顯著提高IIS的效能。網路介面卡，記憶體的升級自然不用多言。
5 Session管理篇
HTTP協議之所以能夠獲得如此大的成功，其設計實現的簡潔性和無狀態串連的高效率是很重要的原因。而為了在無狀態的 HTTP請求和有狀態的用戶端操作之間達到平衡，產生了伺服器端工作階段 (Session)的概念。Session的引入極大地方便了Web編程，但與之對應的Session管理變得異常重要。目前ASP.NET可以通過“進程內”、“進程外專用狀態管理服務”和“SQL Server狀態服務管理”三種方式來進行狀態管理。對於預設的“進程內”管理方式只實現了一個進程內的基於記憶體的狀態管理，故而存在很多問題：
1.所有的 Session 資料都儲存在 Web 服務的進程中，會造成伺服器支援會話數量受到伺服器記憶體資源的限制問題，同時也因為大量非活動會話導致記憶體被無效佔用。
2.伺服器處理序崩潰會導致所有的會話資料丟失。
回到我們的實際系統，目前我們使用Session變數大致有四種用途：
顯然，前三種方式都是小資料量的，我們這裡主要關注第四種方式——Session資料集變數。
把整個資料集存放在Session中，主要是為了用於後續處理或二次加工或使用者翻頁時重新綁定，一般情況下我們在編碼時會忽略資料集的大小給Web-Server和互動時間帶來的影響。實際上，一個超大資料集(記錄數在10萬條以上)所佔用的空間是相當可觀的，如果有數個並發，Web-Server的記憶體會急劇緊張。下表是實際測試的關於SQL執行時間的統計
有一種解決方案是將複雜查詢的“查詢條件”存於Session中。這種方法簡潔又輕便，但是也會造成“由於頻繁查詢導致db-server繁忙”的局面(50萬條記錄的查詢時間大於15s)；理想的解決辦法是實現在資料庫查詢時可進行分頁或者說可以按頁查詢，這時Session中完全可只存放查詢條件，因為互動資料量也不大。Oracle和SQLServer2005中可以比較方便地實現此功能，但SQLServer2000中實現起來比較麻煩，一般都會用預存程序。
考慮到已有系統在實現上並沒有考慮大資料量而且也不是每個頁面或邏輯都會出現大資料量，所以不應該採用單一的 Session管理方案。實際上，我們可以構造具有自適應性的資料訪問執行器和Session管理器，動態地去按不同的方式返回和儲存執行結果。由於目前系統的Session管理員模式為“進程內”(INPROC)模式且由於IIS沒有提供平滑的可配置二級（記憶體/硬碟）緩衝介質切換，所以可自行構造虛擬儲存空間，緩解並發壓力。下面是該方案的總體結構圖：
首先，我們來看一下資料訪問執行的流程圖（圖5-3）。
由圖5-3可知，我們在執行查詢時會設定一個時間閥值，如果在規定時間內執行完畢說明資料量不是很大那麼直接將結果集返回給前台；如果逾時了，則會返回一個小資料集(比如 Top1000)，然後在後台另闢線程繼續查詢動作並將最終結果集儲存到Session，注意這時的資料集在一般情形下是很大的但也可能由於伺服器繁忙造成等待，所以我們會通過Session Manager去動態按適合的方式儲存。
下面是SessionManager類結構的簡單，
必須說明這隻是一個簡單，在具體實現時這個結構會大大豐富。比如，要加上當前Session的儲存方式和儲存數量等。實現 PageSessionManager的目的是為了規範Session的使用尤其是Session資料集變數的使用，我們會根據資料集的大小來自動選擇儲存方式，下面是儲存Session資料集變數的流程圖。
可以看到，我們在SessionManager中引入了一種新的儲存方式——虛擬儲存(Virtual Store)。其目的顯然是為了緩解Web-Server記憶體壓力，提高並發度。經檢測，這種方式還是比較快的；如果把XML儲存到資料庫，則在擷取 XML或讀取XML時會發生逾時異常。實際上，我們是自行構造了一種進程外Session管理器，那麼也自然需要進行Session的清除和失效管理，我們可以在後台運行專門的失效管理進程，具體實現方法可參考。
另一個問題是虛擬隱藏檔與Http進程的對應關係如何建立。這並不難，我們只要建立一個GUID存放在同名的實際Session中，虛擬Session的檔案名稱以此GUID為標識即可。
與儲存相對應的，在通過SessionManager擷取Session值的時候，SessionManager也要自動根據當前儲存方式反饋相應結果，其實現過程並不複雜，這裡就不贅述了。
總的來說，這套解決方案的特點是提高並發度和保證快速響應，但對某些問題的處理也有不便。比如，查詢需要二次加工的記錄集時希望一次得到全部資料集(即使很大)，這時必須設定相應屬性值告訴AdaptiveExecutor，使之按照指定方式執行；還有就是大資料量時，分頁控制項在查詢結束時不能瞬時得到總頁數。
6 代碼篇
這裡的代碼級最佳化是指對具體的代碼實現特別是某個商務邏輯的演算法的改進。在前言中舉的一個例子就屬於代碼最佳化。代碼最佳化是深層次的，需要非常熟悉商務邏輯和資料流，所以難度也是最大的。但在除去商務邏輯之後，我們還是可以對編碼技巧或者演算法結構達成共識的。本篇主要列舉一些實際編碼過程中基於效能考慮應當掌握的方法和注意點。
不要使用不必要的Session，和ASP中一樣，在不必要的時候不要使用Session
不使用不必要的Server Control
不使用不必要的ViewState
不要用Exception控製程序流程
禁用VB和Jscript動態資料類型
使用預存程序完成資料訪問
唯讀資料訪問不要使用DataSet
關閉ASP.NET的Debug模式
使用ASP.Net Output Cache緩衝資料
盡量用SQL返回DataGrid需要綁定的DataSet,盡量不要對DataSet進行二次加工，特別不要對DataSet進行大量刪除，實踐證明這很慢。不如複製部分資料。
盡量不要對DataSet二次加工或者在通過DataSet拼成對象集；顯然，若有40000條記錄就意味著要拼>=40000次的對象
盡量把查詢資料的資料庫操作次數壓縮到最少，盡量1-2次資料庫操作就可完成；如果對查詢得到的DataSet的每項資料再進行查詢，那麼意味著如果有40000條記錄，至少要執行400001次資料庫操作，加上遍曆DataSet、產生對象的時間，是相當驚人的
注意最佳化資料庫查詢操作，比如無條件查詢時不要通過離散值一個一個取；
注意限制大資料量查詢操作，比如預計一個頁面如果一個條件都不加會出現很多資料，則強制至少加一個查詢條件；
不要在頁面載入時預設選擇全部資料，儘管可以方便後續操作，但使用者會以為“還沒有操作就這麼慢”
建議盡量用比較高效的SQL代替後續複雜的DataSet二次加工
僅在需要的時候開啟資料庫連接
一旦資料庫操作完畢，一定關閉串連
在關閉串連時記得刪除臨時對象
在關閉串連前，確保關閉任何使用者定義事務
若要利用串連池，不要使用應用角色(application roles)
顯示非互動性資料，使用SQLDataReader可以獲得最佳效能
通過在SQL中得到html碼比用DataGrid Component格式化資料顯示具有更好的效能
一般而言，在迴圈中使用索引(index)比使用集合(collection)具有更好的效能。因為CLR (Common Language Runtime)有時可以根據資料索引進行最佳化，而集合則不然
注意共用那些經過複雜處理或漫長查詢才得到的資料
在頁面跳轉時記得終止當前頁面的處理
如果頁面載入或後台計算中有一些資料不相關的處理邏輯，可以考慮採用多線程；頁面載入也可以考慮逐步載入(Response.Flush())
有大量串連的字串操作不要使用+，改用StringBuilder
7 Reference
1. http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/maintain/optimize/perflink.mspx
2. http://www0.ccidnet.com/tech/web/2001/09/28/58_3369.html
3. http://msdn.microsoft.com/library/chs/default.asp?url=/library/CHS/cpguide/html/cpconaspoptimization.asp
4. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt06.asp
5. http://www.microsoft.com/china/technet/itsolutions/net/maintain/netopsgd.asp
6. http://www.programfan.com/showarticle.asp?id=2548
7. http://www.microsoft.com/china/msdn/library/webservices/asp.net/CachingNT2.mspx
8. http://www.programfan.com/showarticle.asp?id=2548
9. http://www.microsoft.com/china/msdn/library/webservices/asp.net/CachingNT2.mspx
10. http://www.SQL-server-performance.com/asp_net_performance.asp
11. http://www.cnblogs.com/flier/archive/2004/08.html
12. http://soft.yesky.com/SoftChannel/72342380468043776/20050223/1914105.shtml
13. http://jibbering.com/2002/4/httprequest.html
本文轉自
http://idoall.org/blogs/ian/archive/2007/10/31/asp-net.aspx
