Dec 14 2014

IIS asynchronous processing when using Session

Category: � Administrator @ 11:33

First some background.  This all came about since we have a new developer using all the latest Javascript front-end coding tools/practices and he is developing using Apache locally since he is not a Microsoft guy.  So until we could get him into Visual Studio he had gotten along using Apache to develop and even demo the application.

Low and behold, his development workstation running Apache is more than double the speed of IIS on a Windows 2008R2 server. He even has more network hops to get the data he requires than IIS since all the resources for IIS are located on the same subnet.

I couldn't figure out how and why Apache was working so much faster.

Here's the how the application works.  The Javascript front-end makes seven asynchronous calls to the web service to bring back all the data for the home page.  Now that we're moving to a stable IIS configured development platform I ported his code to C# and expected that the IIS calls would run the seven asynchronous calls just like Apache.  Well it doesn't

I had run the gamut on this – from IIS worker threads to all sorts of machine configuration and web configuration changes.  None of that works.

Finally the Network Guy to put a Wire Shark on and it revealed that Apache was opening up seven ports to complete the calls to the web service and IIS was only opening one port to communicate with the web service. Until the network guy revealed that this was happening I was completely stumped.

Basically IIS ended up blocking the results from returning since they are all on the same port.  IIS thinks that you’re intending to mess with the Session variable so IIS prevents a race condition.

All you have to do is put a page declarative in to make the Session State Read Only.  We do this on a subsequent (data getter) page after the initial Login page so only the Login uses/stores the session variable. 

All other pages just interrogate the variable and this permits IIS to open as many ports as necessary to satisfy the asynchronous calls.  You’ll probably never ever hit this but it’s good to know that IIS still can do its job.

Here's where I found the answer (thank goodness since managers were ready to jettison IIS):



Tags: , , ,