Multi Threaded WS calls hang
-
I am just doing a bit of load testing of a web service. I wrote several test cases in NUNIT to fire off. One test case creates several (5) threads which all start close to each other and call the web service several times. For some reason, usually only one (sometimes 2) of the threads complete, the others seem to hang. It is also never the same thread that completes. Does anyone have a clue why this may be the case? tia stephan
-
I am just doing a bit of load testing of a web service. I wrote several test cases in NUNIT to fire off. One test case creates several (5) threads which all start close to each other and call the web service several times. For some reason, usually only one (sometimes 2) of the threads complete, the others seem to hang. It is also never the same thread that completes. Does anyone have a clue why this may be the case? tia stephan
-
I am just doing a bit of load testing of a web service. I wrote several test cases in NUNIT to fire off. One test case creates several (5) threads which all start close to each other and call the web service several times. For some reason, usually only one (sometimes 2) of the threads complete, the others seem to hang. It is also never the same thread that completes. Does anyone have a clue why this may be the case? tia stephan
Wininet.dll limits connections to an HTTP 1.0 server to 4 and to an HTTP 1.1 server to 2. See http://support.microsoft.com/default.aspx?scid=kb;en-us;320721[^] for details. Similarily, the
ServierPointManageris configured to, by default, limit connections to a particular server to 2. You can change this by settingServicePointManager.DefaultConnectionLimitto something higher, or useHttpWebRequest.ServicePointto get theServicePointfor a particular web address and setServicePoint.ConnectionLimitto something higher than 2. This should apply to all connections made to a particular server. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] -
Wininet.dll limits connections to an HTTP 1.0 server to 4 and to an HTTP 1.1 server to 2. See http://support.microsoft.com/default.aspx?scid=kb;en-us;320721[^] for details. Similarily, the
ServierPointManageris configured to, by default, limit connections to a particular server to 2. You can change this by settingServicePointManager.DefaultConnectionLimitto something higher, or useHttpWebRequest.ServicePointto get theServicePointfor a particular web address and setServicePoint.ConnectionLimitto something higher than 2. This should apply to all connections made to a particular server. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]Maybe I am missing it - but I am not connecting from IE. This is a class dll that is running under nunit doing web service calls. it does so by creating multiple threads that all hit the same web service. Basically some threads simply stop and never return; Stephan
-
Maybe I am missing it - but I am not connecting from IE. This is a class dll that is running under nunit doing web service calls. it does so by creating multiple threads that all hit the same web service. Basically some threads simply stop and never return; Stephan
A WebService request is nothing but a glorified page request over HTTP or HTTPS. So, yes, your using the very same WinInet.dll that IE uses to execute and download its page requests and everything in that article applies to your problem. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
Maybe I am missing it - but I am not connecting from IE. This is a class dll that is running under nunit doing web service calls. it does so by creating multiple threads that all hit the same web service. Basically some threads simply stop and never return; Stephan
In .NET HTTP requests are made via
HttpWebRequest(well, typically). This usesServicePoints and aServiePointManagerto manage connections to servers. Why I explained this with wininet.dll and gave you a link is because it contains more information about why. The .NET Framework SDK documentation isn't clear on a default, so you have to dig into the IL intructions and type metadata in the assembly to know this information (which I do all the time). A web service proxy (client) usesHttpWebRequestinternally and thus is prone to the same conditions that I described in my post. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] -
A WebService request is nothing but a glorified page request over HTTP or HTTPS. So, yes, your using the very same WinInet.dll that IE uses to execute and download its page requests and everything in that article applies to your problem. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
Actually, the .NET BCL doesn't use wininet.dll. That's why I explained about the
ServicePointandServicePointManager. It's the same situation under different APIs, but the KB article explains the "why" a little better than in the .NET documentation (which doesn't even state what the default connection limit is initially set to - you have to dig into the IL - which you know I love - to find that). Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] -
In .NET HTTP requests are made via
HttpWebRequest(well, typically). This usesServicePoints and aServiePointManagerto manage connections to servers. Why I explained this with wininet.dll and gave you a link is because it contains more information about why. The .NET Framework SDK documentation isn't clear on a default, so you have to dig into the IL intructions and type metadata in the assembly to know this information (which I do all the time). A web service proxy (client) usesHttpWebRequestinternally and thus is prone to the same conditions that I described in my post. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]Thanks for the info. I will check this out. At least it appears the problem is with my test code and not with the app I was testing. Stephan
-
In .NET HTTP requests are made via
HttpWebRequest(well, typically). This usesServicePoints and aServiePointManagerto manage connections to servers. Why I explained this with wininet.dll and gave you a link is because it contains more information about why. The .NET Framework SDK documentation isn't clear on a default, so you have to dig into the IL intructions and type metadata in the assembly to know this information (which I do all the time). A web service proxy (client) usesHttpWebRequestinternally and thus is prone to the same conditions that I described in my post. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]This did indeed fix the problem. However it does raise a question. Currently, when the number of threads trying to open simulatneous connections to the service exceed the limit, these threads go into WaitSleepJoin state. So far so good. But when the other threads close their connections, shouldn't these threads be activated by the system? At the moment the threads stay in their suspended state until they get killed by the main process (if they are background threads). Is this a bug or a feature?
-
This did indeed fix the problem. However it does raise a question. Currently, when the number of threads trying to open simulatneous connections to the service exceed the limit, these threads go into WaitSleepJoin state. So far so good. But when the other threads close their connections, shouldn't these threads be activated by the system? At the moment the threads stay in their suspended state until they get killed by the main process (if they are background threads). Is this a bug or a feature?
Looks like they're not being signals, but without digging into the IL (and sorry to say, but it's lunch time here :)) I can't know what the problem is for sure. So I encourage you to do it. If you don't know IL and how t use ildasm.exe in the SDK, it's a great learning experience and can teach you much more about .NET than just reading docs or books. It's likely there's a bug, but don't consider it as such until you've investigated it. If I get a chance later I will look into it. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]
-
Looks like they're not being signals, but without digging into the IL (and sorry to say, but it's lunch time here :)) I can't know what the problem is for sure. So I encourage you to do it. If you don't know IL and how t use ildasm.exe in the SDK, it's a great learning experience and can teach you much more about .NET than just reading docs or books. It's likely there's a bug, but don't consider it as such until you've investigated it. If I get a chance later I will look into it. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]
I have started digging around a bit starting with ServicePoint and SoapRequest. However it looks like there is quite some way to go until I'd come to the point where the threads actually are being put to sleep. I suspect it would happen somewhere in the HTTPRequest class. you might be able to shortcut this as to where in the .NET space the dispatching (and supposedly putting to sleep) is likely to occur. Unfortunately there is this thing called work getting in the way. Cheers Stephan