当您使用 ADO.NET 连接池来管理基于 Web 的应用程序和客户端/服务器 Web 服务应用程序的连接时，您的客户通常会获得更快的连接和更好的总体性能。但是，当您的应用程序或 Web 站点上突然涌入了同时希望进行连接的大量客户时，会发生什么事情呢？您的应用程序会“沉没”，还是会“游泳”？就像救生员一样，您需要仔细监视连接池，以维护它的良好性能，并防止连接池发生溢出。我们首先探讨连接池可能溢出的原因，然后讨论如何编写代码或使用 Windows 性能监视器来监视连接池。
当您使用连接池时，您需要知道许多有关可伸缩性和性能的详细信息。请记住，您需要监视和管理两个基本因素：每个池管理的连接数和连接池的数量。在一个有效的生产系统中，池的数量通常很少（1 到 10），而且，使用中的连接的总数也很少（少于 12 ）有效的查询只用不到一秒钟的时间就可以完成，并断开连接。因此，即使有数百个客户同时访问您的 Web 站点，相对较少的几个连接常常足以处理整个负载。为了使您的应用程序有效地运行，您必须使连接资源处于自己的控制之下，并要监视池的状态，这样，在监视池发生溢出以及您的客户开始抱怨（或离开您的网站）之前您会收到某种警告。
为什么会发生连接池溢出？
参加电子邮件讨论组的人常常抱怨应用程序是如何在测试中是“龙”而在形成为产品时就变成了“虫”的。有时，他们会报告说，当连接了大约 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。这是另一个发生连接“泄漏”的机会。
此外，您还可以使用基于 COM 的 ADO 从 .NET 应用程序创建连接。ADO 利用与 ADO.NET 相同的方式将这些连接组合成池，但不能像您使用 SqlClient ADO.NET 数据提供程序时那样，提供从应用程序监视连接池的方式。
为什么会发生连接池溢出？
参加电子邮件讨论组的人常常抱怨应用程序是如何在测试中是“龙”而在形成为产品时就变成了“虫”的。有时，他们会报告说，当连接了大约 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。这是另一个发生连接“泄漏”的机会。
此外，您还可以使用基于 COM 的 ADO 从 .NET 应用程序创建连接。ADO 利用与 ADO.NET 相同的方式将这些连接组合成池，但不能像您使用 SqlClient ADO.NET 数据提供程序时那样，提供从应用程序监视连接池的方式。
指示 DataReader
孤立连接和溢出池是严重的问题，根据有关这些问题的新闻组讨论的数量来看，它们十分常见。这些问题最有可能是由 DataReader 引起的。为了测试 DataReader 的行为，我编写了一个 Windows 窗体 (WinForms) 示例应用程序，该示例突出了 CommandBeh***ior.CloseConnection 选项。（您可以在 http://www.sqlmag.com 上输入 InstantDoc ID 39031 来下载此应用程序）。您可以在使用 SqlCommand 对象的 ExecuteReader 方法来执行查询并返回 DataReader 时设定此选项。我的测试应用程序显示，如果不显式关闭 DataReader（或 SqlConnection），即使使用此选项，连接池还是会溢出。当代码所请求的连接数超过连接池的容量时，该应用程序就会引发异常。
有些开发人员坚持认为，如果您设置 CommandBeh***ior.CloseConnection 选项，则 DataReader 及其相关联的连接会在 DataReader 完成数据读取时自动关闭。这些开发人员的看法不完全正确 — 只有当您在 ASP.NET Web 应用程序中使用复杂的绑定控件时，该选项才以这种方式工作。在整个 DataReader 结果集中循环到其行集的末尾（也就是说，当 Dr.Read — DataReader 的 Read 方法 — 返回 False 时）还不足以触发连接的自动关闭。不过，如果您绑定到一个复杂的绑定控件（例如，DataGrid），该控件则会关闭 DataReader 和连接 — 前提条件是您设置了 CommandBeh***ior.CloseConnection 选项。
如果您通过使用另一个 Execute 方法（例如，ExecuteScalar、ExecuteNonQuery 和 ExecuteXMLReader）执行查询，则您需要负责打开 SqlConnection 对象，而且，更重要的是，在查询结束时关闭该对象。如果您忘记了进行关闭，孤立连接会迅速地积累起来。