ASP.NET 性能瓶颈之谜
经典的 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 limit 设置为 0。
我使用 ANTS profiler 运行了代码，结果表明线程阻塞并没有显着影响。
非常非常欢迎的想法！
A classic ASP.NET app - AppSrv + MS SQL DB. Both servers are heavy-lifters 8 cores, 20 GB of RAM. When load testing, the throughput goes somewhere to 400 VirtualUsers (according to LoadRunner) with CPU being approximately 30% utilized an DB server primarily idling - response times go dramatically up, to the point of unresponsive.
The usual suspects, such as Max Pool being exhausted and conn limit on ASP.NET set are not at fault: Max Pool is set to 200 and about 80 conns are used; conn limit is set to 0.
I ran with ANTS profiler the code and it showed that Thread blocking did not contribute significantly.
Ideas very very welcome!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
使用一些适当的唯一请求 ID 将日志记录添加到您的应用程序中，以便您可以有效地跟踪页面加载中每个操作所需的时间。 例如，在每次数据库调用之前和之后进行日志记录将显示数据库调用是否花费了很长时间。
正如其他人所建议的，在数据库端添加日志记录/分析将显示是否死锁（或类似）。
Add logging to your app with some appropriate unique request ID so you can effectively trace how long each operation within a page load takes. For instance, logging before and after every database call will show whether the database calls are taking a long time or not.
As others have suggested, adding logging/profiling on the database side will show whether that's deadlocked (or similar).
我们最近使用以下IIS 性能设置指南调整了我们的 Web 应用程序事实证明非常成功。
我们更改了两个服务器特定设置；
工作集内存使用 - 运行 Windows Server™ 2003 的服务器默认配置为在分配内存时优先考虑文件系统缓存而不是工作集。 Microsoft 这样做是因为 Windows 受益于拥有大型文件系统缓存。 由于 IIS 运行在 Windows 操作系统之上，因此它还受益于拥有大型文件系统缓存。 但是，如果您的服务器是专用 IIS 服务器，则将优先级转移到工作集可能会获得更好的性能。 其背后的原因是，如果优先考虑文件系统缓存，则可分页代码通常会写入虚拟内存。 下次需要此信息时，必须将其他内容分页到虚拟内存，并且必须将先前分页的信息读入物理内存才能使用。 这导致处理速度非常慢。
网络吞吐量 - 默认情况下，运行 Windows Server 2003 的服务器配置为在分配内存时优先考虑文件系统缓存而不是进程的工作集（通过服务器属性最大化文件共享的数据吞吐量）。 尽管基于 IIS 6.0 的服务器受益于大型文件系统缓存，但提供文件系统缓存首选项通常会导致 IIS 6.0 可分页代码写入磁盘，从而导致长时间的处理延迟。 为了避免这些处理延迟，请设置服务器属性以最大限度地提高网络应用程序的数据吞吐量。
专用 Web 服务器上不需要以下服务：
We recently tuned our web application using the following IIS performance settings guide which proved very succesfull.
There were two server specific settings we changed;
Working Set Memory Usage - Servers running Windows Server™ 2003 are configured by default to give preference to the file system cache over the working set when allocating memory. Microsoft does this because Windows benefits from having a large file system cache. Being that IIS rides on top of the Windows operating system, it also benefits from having a large file system cache. If your server is a dedicated IIS Server, though, you might see better performance if you shift priority to the working set instead. The reason behind this is if preference is given to the file system cache, the pageable code is often written to virtual memory. The next time this information is needed, something else must be paged to virtual memory and the previously paged information must be read into physical memory before it can be used. This results in very slow processing.
Network Throughput - By default, servers running Windows Server 2003 are configured to give preference to the file system cache over the working sets of processes when allocating memory (through the server property Maximize data throughput for file sharing). Although IIS 6.0–based servers benefit from a large file system cache, giving the file system cache preference often causes the IIS 6.0 pageable code to be written to disk, which results in lengthy processing delays. To avoid these processing delays, set server properties to maximize data throughput for network applications.
The following services are not required on a dedicated Web server:
问题可能出在您的
machine.config文件中。您应该检查以下配置参数：
maxconnectionmaxIoThreadsmaxWorkerThreadsminFreeThreadsminLocalRequestFreeThreads简短说明检查：IIS 6.0 性能调整
ASP.NET 1.1 和 ASP 之间存在一些差异.NET 2.0
ASP.NET 1.1
有关一些实用值的指南，您可以在以下位置找到：
对于任何实际用途来说，默认值都太低，应根据链接文章中的建议进行更正。
ASP.NET 2.0
参数已移至
processModel部分，并且参数会自动配置。除了自动配置之外，您还可以手动设置参数值，因此您应该检查：
processModel是否启用autoConfig是否设置为true或
有关详细说明请检查：ASP.Net 2.0 流程模型
Problem is probably in your
machine.configfile.You should check following configuration parameters:
maxconnectionmaxIoThreadsmaxWorkerThreadsminFreeThreadsminLocalRequestFreeThreadsFor short description check: IIS 6.0 Tuning for Performance
There are some differences between ASP.NET 1.1 and ASP.NET 2.0
ASP.NET 1.1
Guidelines about some practical values you can find in:
Default values are way to low for any practical use and should be corrected according to suggestions in linked articles.
ASP.NET 2.0
Parameters are moved to
processModelsection and parameters are auto configured.Besides auto configuration, you can manually set parameter values, so you should check if:
processModelis enabledautoConfigis set totrueor
For detailed description check: ASP.Net 2.0 processModel
当没有 CPU 被占用并且页面往往变得无响应时，我的第一个预感是数据库锁定。 当不释放表上的锁时，一个线程可以保留其余线程，这会导致数据库服务器空闲时出现无响应页面。
您能否使用 SQL 监控工具来验证数据库计算机上的正确使用情况并查看所有用户是否正确获取数据？
另一件事； 您能提供有关内存使用的哪些信息？
When no CPUs are hosed and pages tend to become unresponsive, my first hunch is database locking. One thread can hold up the rest when not releasing a lock on a table, which results in non responsive pages while idling your db server.
Can you use a sql monitoring tool to verify proper usege on the database machine and see if all users get their data properly?
One other thing; what info can you give on memory use?
主机是否使用应用程序池？
您是否尝试将数量增加到 5 到 10
Does the host utilize App Pool?
Did you try increase the number to 5 to 10 in
还要检查网络饱和度。 确保负载测试机器和 Web 服务器之间的网络连接没有达到最大。 另外，如果您在 Web 和数据库服务器之间返回大量文本/二进制数据，请监视该网络连接。
Also check for network saturation. Make sure you aren't maxing out the network connection between your load test machine and the web server. Also, if you are returning alot of heavy text/binary data between your web and database server monitor that network connection.
这可能不太可能，但您可以尝试通过模式和实践检查器运行代码来查看如果它发现任何容易实现的目标。
It may be a long shot, but you can try running your code through the Patterns and Practices Checker to see if it finds any low hanging fruit.