NET 連接池救生員

防止可淹沒應用程序的池溢出

William Vaughn

大多數 ADO.NET 數據提供程序使用連接池，以提高圍繞 Microsoft 斷開連接的 .NET 結構構建的應用程序的性能。應用程序首先打開一個連接（或從連接池獲得一個連接句柄），接著運行一個或多個查詢，然后處理行集，最后將連接釋放回連接池。如果沒有連接池，這些應用程序將花費許多額外時間來打開和關閉連接。

當您使用 ADO.NET 連接池來管理基于 Web 的應用程序和客戶端/服務器 Web 服務應用程序的連接時，您的客戶通常會獲得更快的連接和更好的總體性能。但是，當您的應用程序或 Web 站點上突然涌入了同時希望進行連接的大量客戶時，會發生什么事情呢？您的應用程序會“沉沒”，還是會“游泳”？就像救生員一樣，您需要仔細監視連接池，以維護它的良好性能，并防止連接池發生溢出。我們首先探討連接池可能溢出的原因，然后討論如何編寫代碼或使用 Windows 性能監視器來監視連接池。

正如我于 2003 年 5 月發表的 “Swimming in the .NET Connection Pool” (InstantDoc ID 38356) 一文中討論的那樣，當您使用連接池時，您需要知道許多有關可伸縮性和性能的詳細信息。請記住，您需要監視和管理兩個基本因素：每個池管理的連接數和連接池的數量。在一個有效的生產系統中，池的數量通常很少（1 到 10），而且，使用中的連接的總數也很少（少于 12 ）有效的查詢只用不到一秒鐘的時間就可以完成，并斷開連接。因此，即使有數百個客戶同時訪問您的 Web 站點，相對較少的幾個連接常常足以處理整個負載。為了使您的應用程序有效地運行，您必須使連接資源處于自己的控制之下，并要監視池的狀態，這樣，在監視池發生溢出以及您的客戶開始抱怨（或離開您的網站）之前您會收到某種警告。

為什么會發生連接池溢出？

GPS平臺、網站建設、軟件開發、系統運維，找森大網絡科技！

參加電子郵件討論組的人常常抱怨應用程序是如何在測試中是“龍”而在形成為產品時就變成了“蟲”的。有時，他們會報告說，當連接了大約 100 個客戶端時，應用程序會停止或掛起。請記住，一個池中的默認連接數是 100。如果您嘗試從池中打開 100 個以上的連接，ADO.NET 會使應用程序的連接請求排隊等候，直到有空閑的連接。應用程序（及其用戶）將這種情況視為進入 Web 頁的延遲或視為應用程序死鎖。讓我們首先討論一下這個問題是如何產生的。

在 ADO.NET 中，SqlClient .NET 數據提供程序為您提供了兩種打開和管理連接的方法。首先，當您需要手工管理連接時，可以使用 DataReader 對象。利用這種方法，您的代碼將構造一個 SqlConnection 對象，設置 ConnectionString 屬性，然后使用 Open 方法來打開連接。當代碼完成 DataReader 后，您要在 SqlConnection 對象停止作用之前關閉 SqlConnection。要處理行集，您可以將 DataReader 傳遞到應用程序中的另一個例程，但仍然需要確保 DataReader 及其連接處于關閉狀態。如果您不關閉 SqlConnection，代碼會“泄漏”每個操作的連接，于是連接池對連接進行累積，最后便發生溢出。與 ADO 和 Visual Basic (VB) 6.0 中的情況不同，.NET 垃圾回收器不會為您關閉 SqlConnection 并進行清理。我稍后要討論的 清單 1 顯示了如何打開連接和生成 DataReader 以從一個簡單的查詢返回行集，來向連接池施加壓力的。

您也可能在使用 DataAdapter 對象時遇到問題。DataAdapter Fill 和 Update 方法可自動打開 DataAdapter 對象的連接，并在數據 I/O 操作完成后關閉該連接。不過，如果該連接在執行 Fill 或 Update 方法時已經處于打開狀態，那么，ADO.NET 在方法執行完以后不會關閉 SqlConnection。這是另一個發生連接“泄漏”的機會。