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