本頁內容    ASP.NET 1.x 中的異步頁  ASP.NET 2.0 中的異步頁  異步數據綁定  異步調用 Web 服務  異步任務   
包裝它
 
 
 
 
ASP.NET 2.0 提供了大量新功能，其中包括聲明性數據綁定和母版頁，成員和角色管理服務等。但我認為最棒的功能是異步頁，接下來讓我告訴您其中的原因。
當 ASP.NET 接收針對頁的請求時，它從線程池中提取一個線程并將請求分配給該線程。一個普通的（或同步的）頁在該請求期間保留線程，從而防止該線程用于處理其他請求。如果一個同步請求成為 I/O 綁定（例如，如果它調用一個遠程 Web 服務或查詢一個遠程數據庫，并等待調用返回），那么分配給該請求的線程在調用返回之前處于掛起狀態。這影響了可伸縮性，原因是線程池的可用線程是有限的。如果所有請求處理線程全部阻塞以等待 I/O 操作完成，則其他請求排入隊列等待線程釋放。最好的情況是吞吐量減少，因為請求等待較長的時間才能得到處理。最壞的情況則是該隊列填滿，并且 ASP.NET 因 503“Server Unavailable”錯誤使后續請求失敗。
異步頁為由 I/O 綁定的請求引起的問題提供優秀的解決方案。頁處理從線程池線程開始，但是當一個異步 I/O 操作開始響應 ASP.NET 的信號之后，該線程返回線程池。當該操作完成時，ASP.NET 從線程池提取另一個線程，并完成該請求的處理。由于線程池線程得到了更高效的使用，因此提高了可伸縮性。那些掛起等待 I/O 完成的線程現在可用于服務其他請求。直接的受益方是不執行長時間 I/O 操作并因此可以快速進出管線的請求。長時間等待進入管線會對此類請求的性能帶來不小的負面影響。
ASP.NET 2.0 Beta 2 異步頁基礎結構的相關文檔很少。讓我們展望一下異步頁的前景，從而彌補這點不足。請記住，本專欄涉及 ASP.NET 2.0 和 .NET Framework 2.0 的測試版本。 ASP.NET 1.x 中的異步頁
ASP.NET 1.x 本質上不支持異步頁，但是通過堅韌的努力和不懈地創新可以生成異步頁。有關更多概述信息，請參閱 MSDN®Magazine 2003 年 6 月刊的文章“Use Threads and Build Asynchronous Handlers in Your Server-Side Web Code”，該文章的作者是 Fritz Onion。
這里的技巧是，在一個頁的代碼隱藏類中實現 IhttpAsyncHandler，從而提示 ASP.NET 通過調用 IHttpAsyncHandler.BeginProcessRequest 來處理請求，而不是通過調用該頁的 IHttpHandler.ProcessRequest 方法。然后，您的 BeginProcessRequest 實現可以啟動另一個線程。該線程調用 base.ProcessRequest，使得頁進入其常規請求處理生命周期（完成諸如 Load 和 Render 的事件），但是在非 ThreadPool 線程上例外。同時，啟動新線程之后 BeginProcessRequest 立即返回，從而允許執行 BeginProcessRequest 的線程返回線程池。
這是基本思想，但細節中還有很多注意事項。其中，您需要實現 IAsyncResult，并從 BeginProcessRequest 中返回它。這通常意味著創建一個 ManualResetEvent 對象，并且當 ProcessRequest 在后臺線程中返回時向其發送信號。此外，您必須提供調用 base.ProcessRequest 的線程。遺憾的是，多數用于將工作移到后臺線程的常規技術（包括 Thread.Start、ThreadPool.QueueUserWorkItem 和異步委托）在 ASP.NET 應用程序中都是起反作用的，因為它們或者從線程池“偷盜”線程，或者有不受限制的線程增長的危險。正確的異步頁實現使用自定義線程池，但自定義線程池類不容易編寫（有關更多信息，請參閱 MSDN Magazine 2005 年 2 月刊的 .NET Matters 專欄）。
主要是在 ASP.NET 1.x 中生成異步頁并非不可能，而是有些乏味。在嘗試一、兩次之后，您不禁會想一定會有更好的方法。目前，這個好方法就是 ASP.NET 2.0。 返回頁首 ASP.NET 2.0 中的異步頁