经典的ASP.NET应用程序 - AppSrv + MS SQL DB。两台服务器都是重型升降机，8核，20 GB RAM。在进行负载测试时，吞吐量大约为400个VirtualUser（根据LoadRunner），CPU大约30％使用主要是空闲的数据库服务器 - 响应时间急剧增加，达到无响应的程度。
通常的嫌疑人，例如Max Pool已经用尽并且对ASP.NET设置的限制没有错误：Max Pool设置为200并且使用了大约80个conns; conn limit设置为0.
我使用ANTS分析器运行代码，它表明线程阻塞没有显着贡献。
非常欢迎您的想法！
答案 0 :(得分：1)
当没有CPU被点击并且页面往往没有响应时，我的第一个预感是数据库锁定。一个线程可以在不释放表上的锁时保留其余部分，这会在空闲数据库服务器时导致无响应的页面。
您是否可以使用sql监视工具验证数据库计算机上的正确usege并查看所有用户是否正确获取了数据？
另一件事;您可以在内存使用方面提供哪些信息？
答案 1 :(得分：1)
使用一些适当的唯一请求ID向您的应用添加日志记录，以便您可以有效地跟踪页面加载中每个操作所花费的时间。例如，在每次数据库调用之前和之后进行日志记录将显示数据库调用是否花费很长时间。
正如其他人所建议的那样，在数据库端添加日志记录/分析将显示它是否已死锁（或类似）。
答案 2 :(得分：1)
我们最近使用以下IIS performance settings指南调整了我们的网络应用程序，该指南证明非常成功。
我们更改了两个服务器特定设置;
工作集内存使用 - 默认情况下，运行Windows Server™2003的服务器配置为在分配内存时优先于工作集上的文件系统缓存。 Microsoft这样做是因为Windows受益于拥有大型文件系统缓存。由于IIS位于Windows操作系统之上，因此拥有大型文件系统缓存也会带来好处。但是，如果您的服务器是专用的IIS服务器，那么如果您将优先级转移到工作集，则可能会看到更好的性能。这背后的原因是如果优先考虑文件系统缓存，则可分页代码通常被写入虚拟内存。下次需要此信息时，必须将其他内容分页到虚拟内存，并且必须先将已分页的信息读入物理内存，然后才能使用。这导致处理非常慢。
网络吞吐量 - 默认情况下，运行Windows Server 2003的服务器配置为在分配内存时通过工作进程集优先于文件系统缓存（通过服务器属性最大化文件的数据吞吐量）共享）。尽管基于IIS 6.0的服务器受益于大型文件系统缓存，但是提供文件系统缓存首选项通常会导致将IIS 6.0可分页代码写入磁盘，从而导致冗长的处理延迟。要避免这些处理延迟，请设置服务器属性以最大化网络应用程序的数据吞吐量
专用Web服务器上不需要以下服务：
答案 3 :(得分：1)
问题可能在您的machine.config文件中。
您应该检查以下配置参数：
maxconnection maxIoThreads maxWorkerThreads minFreeThreads minLocalRequestFreeThreads 简短说明检查：IIS 6.0 Tuning for Performance
ASP.NET 1.1和ASP.NET 2.0之间存在一些差异
ASP.NET 1.1
有关您可以找到的一些实用值的指南：
对于任何实际使用，默认值都是低的，应根据链接文章中的建议进行更正。
ASP.NET 2.0
将参数移至processModel部分，并自动配置参数。
除自动配置外，您还可以手动设置参数值，因此您应该检查：
processModel已启用autoConfig设为true
有关详细说明，请检查：ASP.Net 2.0 processModel
答案 4 :(得分：0)
主机是否使用App Pool？
您是否尝试将数字增加到5到10
An Application Pool -> Performance ->
Web Garden -> Max Number of worker processes
答案 5 :(得分：0)
同时检查网络饱和度。确保您没有最大限度地减少负载测试机和Web服务器之间的网络连接。此外，如果您在Web和数据库服务器监视该网络连接之间返回了大量重文本/二进制数据。
答案 6 :(得分：0)
这可能是一个很长的过程，但您可以尝试通过Patterns and Practices Checker运行代码，看看它是否找到了任何悬而未决的成果。