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 站点，相对较少的几个连接常常足以处理整个负载。为了使您的应用程序有效地运行，您必须使连接资源处于自己的控制之下，并要监视池的状态，这样，在监视池发生溢出以及您的客户开始抱怨（或离开您的网站）之前您会收到某种警告。
为什么会发生连接池溢出？
参加电子邮件讨论组的人常常抱怨应用程序是如何在测试中是“龙”而在形成为产品时就变成了“虫”的。有时，他们会报告说，当连接了大约 100 个客户端时，应用程序会停止或挂起。请记住，一个池中的默认连接数是 100。如果您尝试从池中打开 100 个以上的连接，ADO.NET 会使应用程序的连接请求排队等候，直到有空闲的连接。应用程序（及其用户）将这种情况视为进入 Web 页的延迟或视为应用程序死锁。让我们首先讨论一