C# Web Application Tuning : PerformWaitCallback

Question

I am using dotTrace Performance 4.5 to profile a .NET 3.5 C# web application. When I record one "user request" (load of page), I see 11 threads with approximately the same timing, 7644 ms.

• Most of the thread descriptions only contain: 100% [Native or optimized code] - 7644 ms
• One says: 100% Microsoft.VisualStudio.WebServer.WebServerApp.Main(String[])
• Last one reads:
  • 86% System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object)
  • 14% PerformWaitCallback (1094 ms) >> 12% = ProcessRequest

Can you tell me:

• Why are there so many threads? (images resources, AJAX, JavaScript)
• What is PerformWaitCallback?
• Why 7644 ms for only 1094 ms of work?

Answer 1

Regarding PerformWaitCallback, this is what the reference source has to say:

Call back helper. This function dispatches requests to the user-callbacks. The work-items are fetched from the per-appdomain queue in a loop until either there is no more work or the quantum has expired. The quantum is enforced to maintain fairness among appdomains.

You can see the full code here.

BTW, I'm not sure if you'll see this in .NET 4.5 - again from the reference source (couldn't find an online version, you'll have to download it from 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();
    } 
}

Answer 2

Why are there so many threads? (images resources, AJAX, JavaScript)

The web server creates a thread pool to manage incoming requests, and there are a number of threads in the pool.

What is PerformWaitCallback?

Don't know for sure, but it looks like the code that waits for a thread pool thread to complete its task.

Why 7644 ms for only 1094 ms of work?

It looks like the profiler is counting the time that some threads are spending waiting for new work. I haven't used dotTrace, but most profilers have a way to configure them so they can identify when threads are waiting vs. working -- based on the info you posted, I suspect the profiler isn't configured quite right.