2

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.

Rob
  • 71
  • 1
  • 2
  • 7

4 Answers4

1

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.

Joseph Kern
  • 9,809
  • 3
  • 31
  • 55
0

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).

Jens Bradler
  • 6,133
  • 2
  • 16
  • 13
  • 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 01 '13 at 08:54
0

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.

Matthew Steeples
  • 1,303
  • 1
  • 10
  • 17
0

It sounds like you're looking for an Application Performance Management tool. There are several for .NET applications and depending on the tool and your budget, you can assess the performance of individual web requests, get transaction traces down to specific lines of code, catch application errors, correlate server subsystems performance (disk, CPU, memory), monitor the performance of dependencies (caching tiers/mechanisms, external web services, databases) and much, much more.

Some common APM tools that come to find and get you started with further research are Dynatrace, AppDynamics, New Relic and Lean Sentry

Do keep in mind that merely buying one of these tools will not solve anything for you. You'll have to engage an expert or learn the tool(s) well enough to collect actionable information but you will probably end up with a lot more detail that simply is not "visible" when you monitor from outside the application without any hooks/apis/etc that reveal some of what's going on under-the-hood.

DRCRON
  • 171
  • 4