asp.net - ASP.NET 应用程序中什么消耗了超过 65% 的时间？

Question

我有一个托管在 Windows 7/IIS 7.5 上的 .Net Framework 4.0、ASP.NET、ASP.NET MVC 3 Web 应用程序。此计算机上已启用 IIS 日志记录并设置为以 W3C 模式登录。

该应用程序是使用Release配置编译的，并已通过<compilation debug='false'部署到IIS。明确设置属性。 Web.config 指定使用基于 SQL Server 的 session 状态。

我在 Global.asax 中分别在 BeginRequest 和 EndRequest 事件中添加了以下语句。结果(即“sw.Elapsed.TotalMilliseconds”)存储在应用程序级别的值列表中。我通过调试页面转储这些值并获得相同的平均值。

// in BeginRequest
HttpContext.Current.Items.Add("RequestStartEnd", System.Diagnostics.Stopwatch.StartNew());

// in EndRequest
var sw = (System.Diagnostics.Stopwatch)HttpContext.Current.Items["RequestStartEnd"];
sw.Stop();

我创建了一个负载测试，该测试针对该应用程序运行单个请求，并发用户负载为 20 个用户。测试在 Visual Studio 2010 Ultimate 版本中运行。

运行负载测试后，我得到的秒表记录的平均时间为 681 毫秒。根据 IIS 处理这些请求的平均时间(我在运行负载测试之前清除了所有日志)是2121 毫秒。 IIS 所花费的平均时间与 Visual Studio 负载测试报告中显示的值相符。

秒表所用时间仅占 IIS 日志/Visual Studio 报告的所用时间的 32%。剩下的68%时间都去哪儿了？

更新 1: 我将 session 状态设置为 InProc 并重新运行负载测试。在这种情况下，秒表报告的平均时间与 IIS 日志报告的平均时间之间的差异增长到 70% 以上!那些时间都去哪儿了？

更新 2: @Peter - 我通过设置跟踪规则来登录状态代码 200 来尝试失败的请求跟踪。接下来，我对 20 个并发用户运行了大约 1.5 分钟的负载测试。查看最后 50 个跟踪文件，发现该报告中的“Time Taken”字段的范围为 750 毫秒到 1300 毫秒。 Visual Studio 报告显示平均。所用时间为 2300ms。在报告中，使用紧凑 View ，我看到以下转换之间所花费的时间发生变化 (1)AspNetStart->AspNetAppDomainEnter (2) ManagedPipelineHandler-启动 ManagedPipelineHandler-结束。 (2) 项可能是我的应用程序的代码。失败请求日志的最大耗时(即 1300 毫秒)和平均耗时之间仍然存在很大差异。 Visual Studio 显示的耗时为 2300 毫秒。如何找到对此的会计处理？不过，感谢您提供这个很棒的提示!

Answer 1

您的负载测试运行了多长时间？如果您在 Windows 7 下运行它，您可能会得到与 Windows 服务器下不同的结果。在突发负载下将线程分配给线程池时可能会遇到问题。 .Net会立即分配线程到线程池min，然后慢慢分配到线程池max。我相信客户端操作系统的默认设置与服务器操作系统的默认设置不同。在客户端操作系统上，默认的最小线程设置可能等于您计算机上的核心数量，这意味着 .net 将慢慢分配更多线程来满足您的突发负载。

一个简单的检查是让您的负载测试运行更长时间，看看两次测量之间的差距是否缩小。