asp.net - 从池中获取连接之前经过的超时时间

Question

我们的网站在一天中的90％时间内都可以正常运行，然后在高峰时段流量约为正常水平的两倍时，一切都会变慢。通常为1秒的页面加载时间需要30秒。检查我们的错误日志，看来这可能是连接池问题。我们有3个Web服务器连接到1个sql服务器数据库。 SQL服务器在所有内核上的利用率都低于25％。

我查看了SQL Server上的“用户连接”计数器，发现在高峰期我们有400多个“用户连接”，但下类时间约为120多个。

我很确定我们将使用MS附带的任何默认设置来处理我们的应用程序池。我该怎么做才能检查是否存在应用程序池问题？将应用程序池大小增加到1000的负面影响(我该怎么做？)。

谢谢!

Answer 1

根据我的经验，您可以从SQL Server收到3种主要的超时类型:

1)InvalidOperationException-客户端无法在命令字符串上指定的超时(默认15秒)之前从其自身的池中获得池化连接。客户端的池已达到最大大小，并且所有池连接都已使用并且在超时之前一直处于使用状态。
2)SQLException-连接超时。客户端的连接池正在创建与数据库的新连接，但是在命令字符串中指定的超时(默认为15秒)之前，数据库不会响应。
3)SQLException-命令超时。已获得连接，但是SQL语句执行命令所花费的时间超过了命令的CommandTimeout属性上指定的超时(默认为30秒)
您的服务器在添加负载之前正常运行的情况听起来像情况＃1。我发现超时非常快-通常为2秒。
我发现解决方案是增加SQL Server中的最大线程数。默认值为零-让SQL Server决定。我已经看到过这样的情况:一个粗壮的服务器坐着很少使用资源，却通过分配太少的线程来限制自己。
您可以使用此transact-sql增加最大线程设置:

sp_configure 'max worker threads', 8192
go
Reconfigure 

然后，重新启动您的SQL服务。

顺便说一句，您可以使用以下命令查看SQL Server当前分配了多少个线程:

select sum(current_workers_count) from sys.dm_os_schedulers

此线程设置在许多连接下SQL Server的执行方式上有很大的不同。一旦线程用完，SQL Server就会变得非常无响应。