Yossi Dahan [BizTalk]

Google
 

Wednesday, February 03, 2010

Wrong impressions with MaxConnection

Recently we’ve done some performance tuning on aspects of our solution, and as part of that we’ve looked at configuring the system.net maxCnnections setting (see Darren Jeffords post on this subject) to increase the number of concurrent calls our application can make to various services it uses.

We’ve looked at this for our BizTalk solution but also for a complex, multi-threaded smart client we’re building.

Initially some have been somewhat sceptical about the effects of this, despite all the information on the web, but when I tried to figure out why the reason became apparent – their observations did not match the expectation – no matter they set in the MaxConnections setting, the amount of time it took, and the number of concurrent calls to the external service remained the same.

Trying to figure out why, we’ve used two scenarios – in one we ran our smart client application and monitored using Fiddler we examined how many concurrent requests are sent to the service; on the other we ran a test application we created specifically for this purpose. Confusingly there were two separate reasons for why the observations did not match our expectations -

In the test scenario, the application and the service we used to test were all done on the local machine. Of course in this case the request to the service does not actually go through the network, and so the system.net MaxConnections setting does not play a part; as soon as we’ve moved the service to another machine the results were as expected.

The smart client application, however, was already pointing at a service on a remote machine, and so there must have been something else there; as timing was a little bit more tricky in this case the guys used Fiddler to look into the requests made where they saw all the requests were getting sent out at the same time, despite setting the MaxConnections to 1.

It turns out, and that I did not know, that Fiddler was the cause of the unexpected behaviour.

I don’t know exactly how Fiddler works, but I suspect it hijacks the requests on the local machine so that from our client point of view the requests never actually went through the network and so the MaxConnections setting has been ignored. Fiddler itself does not adhere to this (I’m guessing it is not a .net application) and so multiple concurrent requests have been forwarded by it to the remote service.

As soon as we’ve removed Fiddler the behaviour was as expected.

Lesson learnt.

0 Comments:

Post a Comment

<< Home