Response time measurements for IIS web application

Question

I have a dot net web application, and would like to measure response time. I currently have two measures. The "inner" measure is made within the web app itself. The "outer" measure is the roundtrip time from the client (including network lag, etc).

Obviously the inner response time is always less than the outer response time, sometimes quite significantly.

What I want is another (possibly more than 1) measure that's between these two measurements. How would I take such measurements? For example, a measure that ignores network transmission time, but starts as soon as the request hits the server machine / IIS / my application pool / etc.

Unfortunately I don't have enough IIS knowledge to even make this question clear, let alone answer it myself.

---

Edit: Some further information

The web application is a c# calculation engine. There's no database access, there are no users. The application exposes a WCF endpoint. Response time is fairly consistent at around 200ms, but sometimes spikes, and it is these spikes I'm concerned about. One source of spikes is the application pool recycle (every 29 hours), but we can schedule that.

I'm measuring performance from a client on the server itself to bypass the network. This eliminates many of the spikes, but not all. I'm running the load at 30% CPU usage by the server. The client cpu usage is negligible.

Solution

What I want is another (possibly more than 1) measure that's between these two measurements. How would I take such measurements?

If you have access to the developers that created this application, get them to write a small instrumentation package (non-blocking!) that allows you to pull this counter out of the application directly.

If you can't you will need to start debugging the application itself to determine how long and where it's spending time in execution.

Since this is a windows machine, you can start with process monitor to get a high level idea of what happens during each request. Then you can move onto more robust debugging tools like windbg logger.exe.

Comments

[Rob]

Yes - I'm already testing from the server machine directly, as the network lag was occasionally significant. My web app is CPU intensive - it performs some complex c# processing. There is no DB, and no user/sessions. I'm measuring performance at ~30% CPU utilization, and the client CPU use is tiny.