（很抱歉，如果这是一个非常长的问题，它说是具体的）

(Sorry if this is a really long question, it said to be specific)

我工作的公司拥有一批网站，其中已经运行了一段时间，没有任何问题的。该应用程序是ASP.NET 2.0，3.5的组合，和4.0，均使用ADO.NET连接到SQL Server的标准实例（在相同的网络服务器）都被托管在IIS7。

The company I work for has a number of sites, which have been running for some time with no problems. The applications are a mix of ASP.NET 2.0, 3.5, and 4.0, all using an ADO.NET to connect to a SQL Server Standard instance (on the same webserver) all being hosted with IIS7.

问题开始的时候，我们搬到了一个升级的网络服务器。我们尽一切努力架设服务器，数据库实例和IIS具有完全相同的设置（除了不同的机器名，而事实上我们从SQLEx preSS为标准已经升级），而据我们可以告诉，我们做到了。两个服务器都运行Windows Server 2008 R2（所有最新更新的应用），并获得了默认安装的。

The problem began when we moved to an upgraded webserver. We made every effort to set up the server, db instance and IIS with the exact same settings (except for the different machine name, and the fact that we had upgraded from SQLExpress to Standard), and as far as we could tell, we did. Both servers are running Windows Server 2008 R2 (all current updates applied), and received a default install.

启动这些应用程序时，其中一个问题是非常明显的。当你到达我们的应用程序的页面本身加载速度极快的登录页面。这是真实的，甚至当你从一个新的机器，不可能在页面缓存，并禁止IIS缓存加载页面。当你输入你的登录信息，然后点击登录按钮的问题实际上是可见的。因为我们的数据库（不是很大）设计的，登录过程必须访问多个数据库，理论上高达150单独的DB，但在实践中只有2个数据库（最小）开口时，会发生通常2.问题甚至。不是一个伟大的设计，但我们必须与它活了。

The problem is very apparent when starting up one of these applications. When you reach the login page of our application, the page itself loads extremely fast. This is true even when you load the page from a new machine that could not possibly have the page cached, with IIS caching disabled. The problem is actually visible when you enter your login information and click the login button. Because of the (not great)design of our databases, the login process must access a number of databases, theoretically up to 150 separate DBs, but in practice usually 2. The problem occurs even when only 2 databases (the minimum) are opened. Not a great design, but we have to live with it for now.

在试图开始打开到数据库的连接，整个过程停止了，每次约20秒，无论您是连接到2 DBS或40.我已运行.NET分析器（JetBrains公司dottrace）反对过程中，我可以采取从它的唯一信息是，一个或所有的呼叫到在SQLConnection.open（）已占90％的时间。这只是发生在第一次使用的应用程序，但问题是由IIS似乎无视我们为它的回收设置的事实加剧，并回收闲置几分钟后，应用程序，导致该问题再次出现。

When trying to initially open a connection to the database, the entire process stops for about 20 seconds every time, regardless of whether you are connecting to 2 dbs or 40. I have run a .NET profiler (jetbrains dottrace) against the process, and the only information I could take from it was that one or all of the calls to sqlconnection.open() was accounting for 90% of the time. This only happens on first-use of the application, but the problem is compounded by the fact that IIS seems to disregard the recycling settings we have set for it, and recycles the application after a few minutes of idle, causing the problem to occur again.

我也尝试使用SQL Server Profiler来看看哪些数据库操作是经济放缓的原因，但所有其他数据库的活动，（而事实上，因为我不得不这样做我们的生产服务器上，因为犯规发生在我们的测试环境中的问题）我无法牵制，是造成停工的具体操作。我会尽量进来深夜，关闭生产工厂运行SQL事件探查器，但我可能无法做到这一点的时候了。

I also tried to use the SQL Server profiler to see which database operations were the cause of the slowdown, but because of all the other DB activity, (and the fact that I had to do this on our production server, because the problem doesnt occur in our test environments) I couldn't pin down the exact operation that was causing the stoppage. I will try coming in late at night and shutting down the production sites to run the SQL profiler, but I might not be able to do this right away.

在研究问题的过程中，我已经尝试了几个解决方案

In the course of researching the problem, I have tried a couple solutions

我以为这可能是域名解析的问题，我想modifiying无论是主机上的Web服务器文件以及给予的ConnectionStrings一个IP地址，而不是服务器名称来解决，没有区别。我已经听到了LLMNR协议导致这样的问题，但我认为试图通过IP连接或hosts文件解析应该已经消除了这种可能性，尽管我承认我从来没有尝试过真正关闭LLMNR。

Thinking it might be a name resolution problem, I tried modifiying both the hosts file on the webserver as well as giving the connectionstrings an IP address instead of the servername to resolve, with no difference. I have heard of the LLMNR protocol causing problems like this, but I think trying to connect by IP or resolving with the hosts file should have eliminated that possibility, tho i admit I never tried actually turning off LLMNR.

我增加了闲置超时，回收的时间间隔等在IIS中，但这并不甚至似乎受到尊重，更谈不上解决问题。这使我相信这是压倒一切的机器上的IIS应用程序设置的设置。

I have increased the idle timeouts, recycling intervals etc in IIS, but this doesn't even seem to be respected, much less solving the problem. This leads me to believe there is a setting overriding the IIS application settings on the machine.

其他多个code修正，其中没有什么不同。是一个SqlServer的设置导致的吗？

multiple other code fixes, none of which made any difference. Is a SqlServer setting causing the problem?

其他的东西，我忘了现在。

other stuff that i forgot by now.

任何想法，经验或凡是将大大pciated帮助我解决这个问题AP $ P $！

Any ideas, experience or whatevers would be greatly appreciated in helping me solve this problem!

推荐答案

我会建议使用非TCP连接，如果你还在运行在本地计算机上的SQL实例。 SQL Server支持多种协议，TCP，命名管道和共享内存是比较常见的。

I would advise using a non-tcp connection if you are still running the SQL instance on the local machine. SQL Server supports several protocols, tcp, named pipes, and shared memory are the more common.

命名管道

Data Source=np:computer\instance

共享内存

Data Source=lpc:computer\instance

我个人preFER共享内存。记住，你需要启用这些协议，并避免配置错误，我建议你关闭所有你不使用。

Personally I prefer the Shared Memory. Remember you need to enable these protocols, and to avoid configuration mistakes I suggest you disable all you are not using.

看http://msdn.microsoft.com/en-us/library/ms187892.aspx

IIS重置

在IIS7有两种方法来配置空闲超时。双方开始通过点击应用程序池部分，然后用鼠标右键单击相应的应用程​​序域。如果单击循环...选项还有一个设置。另一种是在高级设置...下的部分过程模型，你会发现空闲超时（分），确定了到零禁用过程超时。这后来的选择是一个为我们工作。

In IIS7 there are two ways to configure the idle-timeout. Both begin by clicking on the "Application Pools" section and right-clicking the appropriate app domain. If you click the "Recycling..." option there is one setting. The other is in "Advanced Settings..." under the section for "Process Model" you will find "Idle Time-out (minutes)" which set to zero disables the process timeout. This later option is the one that works for us.

如果我是你，我会先解决这个问题，重新启动应用程序域和/或工作进程始终是痛苦的，即使你没有20秒的延迟。

If I were you I'd solve this problem first as restarting the appdomain and/or worker process is always painful even if you don't have a 20 second lag.