I am trying to measure the throughput of a webservice.
In order to do that, I have written a small tool that continuously sends requests and reads responses from a n
There are two important aspects w.r.t performance:
One aspect is as suggested by all, the number of TCP connections been used by client (generally better if these connections are persisted (keep alive = true)) for detail refer to : http://msdn.microsoft.com/en-us/library/system.net.servicepoint.connectionlimit(v=vs.110).aspx, How and where the TCP connection has been created in httpwebrequest, and how is it related to servicepoint? , Why System.Net.ServicePoint.ConnectionLimit uses '7FFFFFFF' (Int32.MaxValue/2147483647) when a client connects to a service on 'localhost'? , System.Net.ServicePointManager.DefaultConnectionLimit and .MaxServicePointIdleTime )
Second aspect is rather than using multiple new threads/or using worker threads to do work in parallel using synchronous calls (like httpwebrequest.getrequeststream) in the code snippet, embracing async model completely (for ex, begin/endrequeststream, or new task variations). This way CPU will be always busy and let I/O completion port thread simply send the response in a worker (thread pool) thread by invoking callback. (you may refer to: How does .NET make use of IO Threads or IO Completion Ports?, http://blog.marcgravell.com/2009/02/async-without-pain.html, HttpWebRequest and I/O completion ports )