经典的ASP.NET应用程序 - AppSrv + MS SQL DB。这两款服务器都是8升核心，20 GB的RAM。负载测试时，吞吐量达到400个VirtualUser（根据LoadRunner），CPU使用率大约为30％，DB服务器主要是空闲的 - 响应时间急剧增加，无法响应。ASP.NET性能瓶颈之谜
通常的嫌疑犯，如Max Pool耗尽和ASP.NET设置的conn限制都没有出现问题：Max Pool设置为200，使用约80个conns; conn限制设置为0.
我使用ANTS分析器运行代码，它显示线程阻塞没有显着贡献。
想法非常非常欢迎！
主机是否使用App Pool？
你尝试增加
An Application Pool -> Performance ->
Web Garden -> Max Number of worker processes
到10号到5当没有CPU都用水管冲洗和页面往往会变得反应迟钝，我的第一直觉是数据库锁定。一个线程可以在不释放对表的锁时阻止其他线程，从而在闲置数据库服务器时导致无响应的页面。
您可以使用sql监视工具来验证数据库机器上的正确使用情况，并查看所有用户是否正确地获取其数据？
另一件事;你可以给内存使用什么信息？
使用一些适当的唯一请求ID将日志记录添加到您的应用程序，以便您可以有效地跟踪页面加载中每个操作需要多长时间。例如，在每次数据库调用之前和之后的日志记录都会显示数据库调用是否需要很长时间。
正如其他人所建议的，在数据库端添加日志记录/分析将显示是否死锁（或类似）。
还检查网络饱和度。确保你的负载测试机和网络服务器之间的网络连接不是最大的。此外，如果您要在网络和数据库服务器之间返回大量文本/二进制数据，则会监视该网络连接。
我们最近使用以下IIS performance settings指南调整了我们的Web应用程序，该指南证明非常成功。
我们更改了两个服务器特定设置;
工作集内存使用情况 - 运行Windows Server™2003的服务器默认配置为在分配内存时优先于工作集上的文件系统缓存。微软这样做是因为Windows受益于拥有大型文件系统缓存。由于IIS是在Windows操作系统之上运行的，因此它还具有大型文件系统缓存。但是，如果您的服务器是专用的IIS服务器，那么如果您将优先级改为工作集，则可能会看到更好的性能。其原因是如果优先考虑文件系统缓存，则可分页代码通常写入虚拟内存。下一次需要该信息时，必须将其他内容分页到虚拟内存，并且在使用之前先前分页的信息必须读入物理内存。这导致处理非常缓慢。
网络吞吐量 - 默认情况下，运行Windows Server 2003服务器配置（用于文件共享通过服务器属性最大化数据吞吐量）分配内存时要优先考虑文件系统缓存诸过程的工作集。尽管基于IIS 6.0的服务器受益于大型文件系统缓存，但提供文件系统缓存首选项通常会导致将IIS 6.0可分页代码写入磁盘，从而导致处理时间过长。为避免这些处理延迟，请设置服务器属性以最大限度地提高网络应用程序的数据吞吐量
下列服务不需要专用的Web服务器上：
这可能是一个长镜头，但你可以尝试通过Patterns and Practices Checker运行代码，看看它是否发现任何低挂水果。
问题可能在您的machine.config文件中。
您应检查以下配置参数：
maxconnectionmaxIoThreadsmaxWorkerThreadsminFreeThreadsminLocalRequestFreeThreads对于简短描述检查：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
您是否尝试过在数据库服务器上运行任何问题的跟踪？ – 2008-10-28 09:10:38
一些更多的信息将会有用： 正在使用多少内存？ 你使用的是什么版本的框架？ 机器是64位还是32位？ 您使用的是什么操作系统？ 什么是网络设置？ 您使用的是什么SQL Server版本？ – Bravax 2008-10-28 09:22:43