我正在使用dotTrace Performance 4.5来分析.NET 3.5 C#Web应用程序。当我记录一个“用户请求”(页面加载)时,我看到11个线程具有大致相同的时序,7644毫秒。
Microsoft.VisualStudio.WebServer.WebServerApp.Main(String[])
System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object)
PerformWaitCallback
(1094 ms)>> 12%= ProcessRequest
PerformWaitCallback
?答案 0 :(得分:3)
为什么有那么多线程? (图像资源,AJAX,JavaScript)
Web服务器创建一个线程池来管理传入的请求,池中有许多线程。
什么是PerformWaitCallback?
不确定,但它看起来像等待线程池线程完成其任务的代码。
为什么只有1094毫秒的工作时间为7644毫秒?
看起来分析器正在计算某些线程等待新工作的时间。我没有使用过dotTrace,但是大多数分析器都有办法配置它们以便它们可以识别线程何时等待与工作 - 根据您发布的信息,我怀疑分析器配置不正确。
答案 1 :(得分:1)
关于PerformWaitCallback
,这是参考来源所说的:
回电助手。此函数将请求分派给 用户回调。工作项从每个应用程序域中获取 在一个循环中排队,直到没有更多的工作或量子有 过期。强制执行量子以保持公平 应用程序域。
您可以看到完整代码here。
顺便说一句,我不确定你是否会在.NET 4.5中看到这一点 - 再次来自参考源(无法找到在线版本,你必须从http://referencesource.microsoft.com/下载)://This type is necessary because VS 2010's debugger looks for a method named
///_ThreadPoolWaitCallbacck.PerformWaitCallback
//on the stack to determine if a thread is a ThreadPool thread or not.
//We have a better way to do this for .NET 4.5, but
//still need to maintain compatibility with VS 2010.
//When compat with VS 2010 is no longer an issue, this type may be removed.
internal static class _ThreadPoolWaitCallback
{
[System.Security.SecurityCritical]
static internal bool PerformWaitCallback()
{
return ThreadPoolWorkQueue.Dispatch();
}
}