HTTP client, SSL and CRL check

We recently experienced a severe spike in latency of our one applications that uses HttpWebRequest to connect to a remote service over SSL under high load. After looking at it from a lot of angles, the thought of the certificate verification being blocked seemed like a possible cause, especially since the application is hosted in a locked-down DMZ and only the necessary minimum access granted to access the service URL. Once we granted access to be able to perform the OCSP and/or CRL checks, transactions started flowing immediately. I found this article at the time explaining the whole process. I also think a contributing factor was that only two active HTTP requests are allowed to a destination at once by default according to RFC 2616, my guess is that the CryptoAPI would adhere to this same limit, so all OCSP/CRL requests queued until the active ones timed out.

HTTP concurrent connections

Our application exposes a webservice interface to clients, and connects to other providers for performing transactions. Whilst doing loadtesting, I noticed that the client connecting to an upstream provider using HttpWebRequest was not opening more than 2 concurrent connections at any time, causing latency to go through the roof and tps not scaling once the number of simultaneous requests to the webservices goes over 5. Googling a bit yielded this link: http://social.msdn.microsoft.com/Forums/en-US/1f863f20-09f9-49a5-8eee-17a89b591007/asynchronous-httpwebrequest-maximum-connections-best-approach-threads-or-delegates?forum=netfxnetcom.

Googling a little bit more I found details about the connectionManagement config section. After adding a section to the application's config file it now scales as expected, with more simultaneous connections increasing the tps as expected.