Question

I’m building a server application that needs to perform a lot of http requests to a couple other servers on an ongoing basis. Currently, I’m basically setting up about 30 threads and continuously running HttpWebRequests synchronously on each thread, achieving a throughput of about 30 requests per second.

I am indeed setting the ServicePoint ConnectionLimit in the app.config so that’s not the limiting factor.

I need to scale this up drastically. At the very least I’ll need some more CPU horse power, but I’m wondering if I would gain any advantages by using the async methods of the HttpWebRequest object (eg: .BeginGetResponse() ) as opposed to creating threads myself and using the synchronous methods (eg: .GetResponse() ) on these threads.

If I go with the async methods, I obviously have to significantly redesign my app, so I’m wondering if anyone might have some insight before I go and recode everything, in case I’m out to lunch.

Thanks!

Answer 1

If you are on Windows NT, then System.Net.Sockets.Socket class always uses IO Completion ports for async operations. And HTTPWebRequest in async mode uses async sockets, and hence will be using IOCP.

Without doing detailed benchmarking, it is difficult to say if our bottleneck is inside HttpWebRequest, or up the stack, in your application, or on the remote side, in the server. But offhand, for sure, asyncc will give you better performance, because it will end up using IOCP under the covers. And reimplementing the app for async is not that difficult.

So, I would suggest that you first change your app architecture to async. Then see how much max throughput you are getting. Then you can start benchmarking and finding out where the bottleneck is, and removing that.