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?

Are you measuring just *one* request? You should start the app up and run *multiple* requests; there's inherent overhead involved in starting up the web application. — casperOne, Nov 21 '11 at 14:17
I "heat up" the app before profiling one request. I get similar results if I run multiple request (N x 8 sec). — Francois, Nov 21 '11 at 14:20
Probably it depends on whether you are using IIS, IIS Express or Web Development Server. — Uwe Keim, Nov 21 '11 at 22:35
for better testing use IIS,also there is a very useful memory profiler ANTS Profiler from RedGate, I prefer using it — Sleiman Jneidi, Dec 01 '11 at 18:51

score 3 · Answer 1 · answered Dec 03 '11 at 00:08

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.

Sorry for my late answer but I was working off the performance issues. If I monitor IIS with DotTrace, there is no more `PerformWaitCallback`, but `System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr, Int32)` with same time differences... — Francois, Mar 13 '12 at 11:18

Ohad Schneider · Accepted Answer · 2013-05-23T08:38:12.073

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();
    } 
}

C# Web Application Tuning : PerformWaitCallback

2 Answers2