views:

115

answers:

1

I'm developing an asp.net webservice application to provide json-formatted data to a widget that uses jQuery.ajax to make the request. I've been using the FireBug Net view to check how long the requests for data take.

In my initial prototype I was simply requesting static json data files, which on my dev machine were obviously returned very quickly by IIS - in around 2 to 5ms, even if not present in the browser's cache.

Now I've connected to the webservice I'm concerned that the data requests are way too slow, as they are taking consistently around 200ms to return. (This is even after the first request which is obviosuly compiling stuff and taking around 6 whole seconds.) I have removed all database/processing overhead from the web request, so it should take very little time to process, and this is also still on the local dev machine, so no network latency. The overhead is no better with a release build and on a production server.

My question is this:

Is this response time of around 200ms the best I can expect from a .net web service that is simply returning 'Hello World'? If it is possible to do much better, then what on earth might I be doing wrong? If it isn't possible, what would you do instead?

A: 

If it's really doing nothing in terms of connecting to a database etc, then you should be able to get a much better response time that 200ms.

If you measure the time at the server side instead of the client side, what do you see? Have you tried using WireShark to see what's happening in the network?

Basically you want to be able to create a timeline as accurately as possible, showing when the client sent the request, when the request hit the server, when your server-side code received the request, when your server-side code finished processing the request, when the server actually sent the response, and when the client actually received the response.

At that point you can work out where the bottleneck is.

Jon Skeet
Thanks for the tip off on WireShark, I've not used that before. This shows the time between the request hitting the server and response leaving it's port taking around 170ms, so that's definitely the biggest part of it. My web server code is doing no processing at all, just returning a string parameter directly back to the client.
Paul Harrison
Hmm. That's not good. You may be able to put some more logging into the process so you can see something of where the rest of the time's going. What happens if you do an ASP.NET non-webservice call (e.g. directly to a custom handler)?
Jon Skeet
I've just tried a custom handler call - and it's just the same slowness. Oh well...My alternative solution is to let the webservice calls that are writing data actually write out json files to disk to be served up later. (The site will have many more reads than writes.)You've answered the main part of my question - it _should_ be faster than this.
Paul Harrison
I don't see how making the web service calls write out to disk would really speed things up - it sounds like it's a fixed latency due to just getting the request, rather than a problem in terms of how much work is required to process it. Or do you mean you'd then make the AJAX "fire and forget" so the latency isn't as much of a problem? I do wonder where that time's going... you might want to run some of the SysInternals tools to work out if IIS is doing something like a reverse DNS lookup which is taking a long time.
Jon Skeet
Ok - I think I'm getting somewhere. My web service was in a sub-directory of a bigger asp.net application. Stripping the web service down to its bare bones in a separate server, and responses are down to 10-12ms as I'd hoped. Thanks for confirming that they should go faster - I'd pretty much given up the will to try any further. Now I just need to get the powers-that-be to agree to a separate server...
Paul Harrison