在 ASP.Net 应用程序中从连接池获取新连接超时。我需要缓解建议

Question

在中等负载下，我们偶尔会在某个数据库上收到以下错误。

“System.InvalidOperationException：超时已过期。从池中获取连接之前超时时间已过。发生这种情况的原因可能是所有池连接都在使用中并且已达到最大池大小。”

我已经梳理了代码，我们正在像我们应该的那样关闭finally块中的连接，除了我们已经建立的少数情况下很少被调用。我们将在下一个版本中修复这些代码，但为了解决当前的生产问题，我建议将最大池大小增加到 300。我们当前遇到的最大并发用户数约为 110，这显然超过了默认池大小（ 100）。

我还建议确保特定 SQL Server 实例的所有连接字符串都相同，以避免创建不必要的多个连接池。我希望当我们需要在单个 SQL Server 实例中切换数据库时，我们可以在实际的 SQL 查询之前使用USE [Database]语句。

你们有什么想法、指示、建议或陷阱需要我们注意吗？

Answer 1

您必须消除连接泄漏。如果池耗尽的原因是泄漏，将其增加到 300 只会推迟不可避免的情况。如果您在 10000 次调用中泄漏一个连接（即“非常罕见”），并且您有 110 个并发请求，例如每次调用 5 秒，那么您的泄漏率约为每 8 分钟一个连接，这将耗尽池中的资源。 13小时。不过，随着可用池大小的缩小，超时将开始出现得更早。

如果您有确凿的证据表明根本原因不是泄漏，而是调用率与池大小，那么您应该增加池大小。无论您决定使用的池大小是什么，如果您的请求在整个请求持续时间内需要 1:1 连接，那么您需要对 HTTP 接受进行限制/排队，以便它不会超过您的池大小。如果没有，您仍然可能会遇到耗尽池的峰值。

此外，您还可以考虑使用更具弹性的连接工厂，如果池耗尽，它会重试并尝试非池化连接。当然，这与我之前的观点是密切相关的，即如果您校准最大 HTTP 接受计数以匹配池大小，那么池就不会被耗尽（除非您泄漏，回到第一个）。但我不建议这样做，我认为在 http.sys 区域中排队请求比在应用程序资源分配区域中排队要好得多（即限制最大接受的 HTTP 调用）。

最后但并非最不重要的一点是，减少每次通话的持续时间。如果您的呼叫平均耗时 5 秒，那么您会看到 110 个并发连接，每秒仅 22 个请求。如果通过将 SQL 瓶颈消除到 1 秒来将调用持续时间减少到 1 秒，那么您将能够每秒处理 110 个请求，以达到相同的资源上限（110 个并发请求），即流量增加 5 倍。最大的罪魁祸首通常是表扫描，请确保所有查询都使用合理的 SQL 并具有最佳的数据访问路径。正如 David 所说，SQL Profiler 是您的朋友。

您还可以使用SqlConnection.ChangeDatabase更改数据库。