一个经典的 ASP.NET 应用程序 - AppSrv + MS SQL DB。两台服务器都是 8 核、20 GB RAM 的重型服务器。在负载测试时，吞吐量达到 400 个虚拟用户（根据 LoadRunner），CPU 使用率约为 30%，数据库服务器主要处于空闲状态 - 响应时间急剧增加，达到无响应的程度。
通常的怀疑，例如 Max Pool 被耗尽和 ASP.NET 设置的 conn 限制没有问题：Max Pool 设置为 200，使用了大约 80 个 conn；conn 限制设置为 0。
我用 ANTS profiler 运行了代码，它表明线程阻塞没有显着贡献。
非常欢迎提出想法！
当没有 CPU 被占用并且页面往往变得无响应时，我的第一个预感是数据库锁定。当不释放表上的锁时，一个线程可以保留其余的线程，这会导致在空闲数据库服务器时页面无响应。
您可以使用 sql 监控工具来验证数据库机器上的正确使用，并查看是否所有用户都正确获取了他们的数据？
另一件事；您可以提供有关内存使用的哪些信息？
使用一些适当的唯一请求 ID 将日志记录添加到您的应用程序，以便您可以有效地跟踪页面加载中的每个操作需要多长时间。例如，每次数据库调用之前和之后的日志记录将显示数据库调用是否需要很长时间。
正如其他人所建议的那样，在数据库端添加日志记录/分析将显示这是否是死锁的（或类似的）。
我们最近使用以下IIS 性能设置指南调整了我们的 Web 应用程序，该指南非常成功。
我们更改了两个特定于服务器的设置；
工作集内存使用- 运行 Windows Server™ 2003 的服务器默认配置为在分配内存时优先考虑文件系统缓存而不是工作集。Microsoft 这样做是因为 Windows 受益于拥有大型文件系统缓存。由于 IIS 位于 Windows 操作系统之上，因此它还受益于拥有大型文件系统缓存。但是，如果您的服务器是专用的 IIS 服务器，则如果您将优先级转移到工作集，您可能会看到更好的性能。这背后的原因是，如果优先考虑文件系统缓存，可分页代码通常会写入虚拟内存。下次需要此信息时，必须将其他内容分页到虚拟内存，并且必须先将先前分页的信息读入物理内存，然后才能使用它。这导致处理非常缓慢。
网络吞吐量- 默认情况下，运行 Windows Server 2003 的服务器配置为在分配内存时优先使用文件系统缓存而不是进程的工作集（通过服务器属性最大化文件共享的数据吞吐量）。尽管基于 IIS 6.0 的服务器受益于大型文件系统缓存，但提供文件系统缓存首选项通常会导致 IIS 6.0 可分页代码写入磁盘，从而导致长时间的处理延迟。要避免这些处理延迟，请设置服务器属性以最大化网络应用程序的数据吞吐量。
专用 Web 服务器上不需要以下服务：
问题可能在您的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
主机是否使用应用程序池？
您是否尝试将数字增加到 5 到 10
An Application Pool -> Performance ->
Web Garden -> Max Number of worker processes
还要检查网络饱和度。确保您的负载测试机器和 Web 服务器之间的网络连接没有达到极限。此外，如果您在 Web 和数据库服务器之间返回大量繁重的文本/二进制数据，请监控该网络连接。
这可能是一个很长的尝试，但您可以尝试通过模式和实践检查器运行您的代码，看看它是否找到了任何容易实现的目标。