我有一个。net Framework 4.0, ASP。净,ASP。. NET MVC 3 web应用程序托管在Windows 7/IIS 7.5。在这台机器上启用了IIS日志记录，并设置为以W3C模式登录。
应用程序是通过使用Release配置编译的，并且已经部署到IIS并显式设置了<compilation debug='false'属性。网络。config指定使用基于SQL Server的会话状态。
我在Global中增加了以下语句。分别在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最终版中运行的。
运行负载测试后，我得到秒表记录的平均时间为681毫秒。这些请求在每个IIS上花费的平均时间是2121毫秒(我在运行负载测试之前清空了所有日志)。每个IIS所花费的平均时间与Visual Studio负载测试报告中显示的值相符。
秒表时间只占IIS logs/Visual Studio报告的时间的32%。另外68%的时间去哪了?
更新1:我将会话状态设置为InProc并重新运行负载测试。在这种情况下，秒表报告的平均时间和IIS日志报告的平均时间之间的差异增长到70%以上!!这些时间都去哪儿了?
更新2:@Peter -我通过在登录状态码为200的情况下添加跟踪规则来尝试失败的请求跟踪。接下来，我用20个并发用户运行负载测试，耗时约1.5分钟。检查了最后50个跟踪文件，发现该报告中的"时间占用"字段的范围为750毫秒到1300毫秒。Visual Studio报告显示平均耗时为2300ms。在使用紧凑视图的报告中，我看到在以下转换之间所花费的时间发生了变化(1) AspNetStart -> AspNetAppDomainEnterManagedPipelineHandler-start ManagedPipelineHandler-end。(2)项可能是我的应用程序代码。每个失败请求日志所花费的最大时间(即1300ms)与Visual Studio显示的平均时间(2300ms)之间仍然存在很大差异。怎么解释呢?谢谢你的建议!
您要运行多长时间的负载测试?如果你在windows 7下运行它，你可能会得到与在windows服务器上不同的结果。在突发负载下，你可能会遇到线程分配到线程池的问题，. net会立即将线程分配到线程池的最小值，然后慢慢分配到线程池的最大值。我相信客户端操作系统的默认设置与服务器操作系统的不同。可能在客户端操作系统上，默认的最小线程设置等于您机器上的内核数，这意味着。net将慢慢地分配更多线程来满足您的突发负载。
一个简单的检查是让您的负载测试运行更长时间，看看您的两个测量之间的差距是否缩小。
有一个更好的方法来查看你的应用程序的内部，通过使用"失败请求跟踪规则"
http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/这样你就可以准确地跟踪你的应用程序在IIS中所做的事情
我建议查看MvcMiniProfiler。它是一个NuGet包，你可以添加和连接(几乎毫不费力)，真正打破了MVC应用程序中各个点的执行时间。你可以看到每个请求的实时视图，以及任何瓶颈所在。
更多信息:
- http://code.google.com/p/mvc-mini-profiler/
- http://www.hanselman.com/blog/NuGetPackageOfTheWeek9ASPNETMiniProfilerFromStackExchangeRocksYourWorld.aspx
- http://www.nuget.org/List/Packages/MiniProfiler
这很可能是托管管道开销和网络(甚至是本地主机或127.0.0.1)的组合，这可能是"丢失"时间可以解释的地方。
- 你提到IIS日志与你的Visual Studio加载相符测试数字-这两个都涉及网络堆栈和托管管道。 你的秒表代码只在ASP中执行。. NET上下文(只是在ASP。. NET执行开始和结束之前)，并且不考虑IIS处理TCP网络请求的开销，解析请求和响应的http头以及传输时间通过托管管道和TCP栈。
- [EDIT]这个比例被夸大了，如果你的ASP。. NET页面的执行时间真的很快，例如，相对于TCP栈的其余部分和为你封送HTTP请求的托管管道，它不会消耗大量的CPU
如果您遇到加载时间过长的问题，这可能与以下几个因素有关:如果您有大量的IO操作，它可能会影响这一点如果你正在做一个表单数据库查询，尝试分析你的SQL语句要么在vs与SQL分析器或SQL服务器内置的分析器，如果你得到很多单独的查询，你可能要考虑使用一些包含在你的linq查询捆绑你的一些数据到单个查询
如果你有很多IO操作，所以你的应用程序不需要连续等待每个IO操作完成，你可能也想考虑使用异步控制器来改善响应时间看到wintellect.com/CS/blogs/jprosise/archive/2010/03/29/..。还有比iis日志更好的日志解决方案，因为它是一个相当老的组件，你可能想看看log4net更通用的日志记录或elmah日志错误和异常，因为这些解决方案可以捆绑一堆日志条目，并在单个操作中写入多个日志条目，还可以提高IO性能