Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

Quick and simple: Start your measurement directly on the very same server machine or (if you are afraid of load implications) in the very same network (usually a DMZ your web application server is located).

Actually you get aware of different performance factors of web applications:

  • your application's net response time (only your application, only one user)
  • your application's gross response time (includes application; web server stack; multiple users; concurrent access to your data sources, devices and network)

It's absolutely normal to see differences in here. The measurement would be doubtful if not.

However if you'd like to avoid measurement errors caused by different network speed, bandwidth, client side problems and so on start your gross response time measurement at your localhost (and mark results according to this) or increase the number of measurement points (clients), time frame of measurement and calculate an average amount (You can create your own JavaScript for this purpose or you can use existing tools e.g. Google Analytics).

share|improve this answer
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. – Rob Oct 1 '13 at 8:54

Sounds like a job for Performance Counters. If you click on start -> Run -> Perfmon.msc then in the app that runs you can add all sorts of monitoring for different aspects of IIS and the system. It should be able to give you end to end answers for IIS requests, including how long they spent waiting to be processed and how long they processed for.

It will also let you save them out to a file or DB if you want to log over longer periods.

You say the CPU is running at 30%. Is it a multi-core computer? If it's got 4 cores and your code isn't parallelised then you could be suffering from maxing out the processor even if it doesn't appear that way.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.