3

I have a custom IHttpModule that is used to log all HTTP requests and responses, and this is currently working very well, but I'd love to extend it so I can determine how long a response actually takes.

The response is logged in the HttpApplication.EndRequest event, but this event fires before the request is actually sent to the web client. While this allows me to determine how long it took for the server to process the response, I'd also love to be able to time how long it actually took for the client to receive the response.

Is there an event, or some other mechanism, which will allow me to intercept after the client has finished receiving the response?

Cleggy
  • 715
  • 9
  • 24
  • In short... no. The server has no visibility to when a client has received the data, you will have to use javascript to call back into the server. They are many example frameworks of this, both open source and commerical. Try integrating Glimpse – Robert Slaney Mar 06 '12 at 20:07
  • For the applications I'm most interested in logging, I have no control of the clients, and these clients are making SOAP calls over HTTP. So it sounds like your approach will not be feasible for my needs. Thanks anyway. – Cleggy Mar 06 '12 at 22:25
  • as best you might be able to work out when the last byte left the server, but this is essentially the same as the IIS logs, and would probably require an ISAPI filter – Robert Slaney Mar 07 '12 at 02:14
  • Yeah, that isn't overly helpful for what I'm trying to achieve, but thanks once again for your input anyway. I guess I was hoping that the call to stream the response to the client was synchronous, and I'd be able to straddle either side of it so I can compute the actual response time, rather than the time it takes the server to process the response. – Cleggy Mar 07 '12 at 03:19
  • the server nows when the client has recevied all bytes.because the server must buffer it. – mo. Mar 11 '12 at 15:37
  • with server i mean IIS or somethin else, not ASP.NET directly – mo. Mar 11 '12 at 19:40

3 Answers3

1

So that would require client-side code. But not entirely clear what you are wanting to measure. From smallest to largest, the timings could be

  1. time inside server application - measured by code which you already have.
    • Your code can set the start from either the "Now()" when it begins, or using the HTTP objects. The first call to a site would see a big difference between these start times, otherwise they should be almost identical.
  2. time on server website - I believe this is already measured by most hosting services like IIS.
  3. server machine - I believe this is what "mo" is referring to. You would have to have some kind of external monitoring on the server machine, ala WireShark.
  4. client machine - again, you would have to have some kind of external monitoring on the client machine. This would be the hardest to get, but I think is really what you are asking for.
  5. client application - this is what you can measure with javascript.

Unless this is the "first call" (see Slow first page load on asp.net site or ASP.NET application on IIS7 - very slow startup after iisreset), I believe that all of these time will be just so close that you can use a "good enough" approach instead.

If you must have a measure of this call's client time, then you are stuck in a bad spot. But if you just want better numbers, just continue to measure 1. (application time) with what you already have, and make sure to also measure the size of the request and response.

Then set a base-line for adjusting that time, by testing on various target client machines.

  • Measure ping times from the client to your server
  • Measure transfer times of moderately large content - both upload and download
  • Finagle the numbers to get your average adjustment

You should end up with a formula like:

[AdjustedTime] = [PingTime] + [ServerTime]
+ ([UploadSpeed] * [RequestSize])
+ ([DownloadSpeed] * [ResponseSize]);

This would be the expected client response time.

Community
  • 1
  • 1
Abacus
  • 2,041
  • 1
  • 18
  • 23
  • You're missing the point of what I was asking for. I needed a way to determine how long it took before the client actually received and finished processing the response. In order to do this, I need some way of hooking into directly after the client has finished receiving the response. – Cleggy May 22 '13 at 01:41
  • (Correcting, yes I misunderstood the question) – Abacus May 23 '13 at 20:47
  • Thanks for your detailed reply. Unfortunately I was looking for a solution that involved no client-side involvement, as I was wanting to profile a SOAP service and ASP.NET website called by third party clients I have no control over. As there doesn't seem to be a way to do this with the ASP.NET framework, my "solution" was to omit this metric altogether. – Cleggy May 24 '13 at 00:41
0

yes you could handle HttpApplication.EndRequest

mo.
  • 3,474
  • 1
  • 23
  • 20
  • No, that is the last event that fires in the HTTP pipeline chain, but it still fires before the content is actually sent to the client. – Cleggy Mar 11 '12 at 19:12
  • with an unbuffered response it should indicate, that the client has received all bytes.because they send directly over the line (correct me if iam wrong). i read http://msdn.microsoft.com/en-us/magazine/cc188942.aspx and it shows, that it work a little different for a buffered response (the default) – mo. Mar 11 '12 at 19:38
0

another way could be to hook (example: windows service to write response-time to a database) into your webserver (IIS) and trace those events.if you want to analyse the time, a client needs to get your content.

but i think, iis is already able todo so.

it depends a littlebit, what you want todo.

mo.
  • 3,474
  • 1
  • 23
  • 20