Okay, pet theory for the day (or remainder thereof...)

DNN startup requires worker threads, but if all the incoming users consume all available threads waiting for .net to start up - then during DNN's startup, when it tries to get it's own worker threads, it would sit there and wait for those threads to become available.  Of course, while it's waiting, .net is still sitting in the app start event, thus the worker threads holding the user requests,slowly start to die off, and then finally, dnn gets started.  I foggily recall somewhere that in the system machine.config you set the max threads per worker .. hmmm.  I need more coffee before starting to glare through that msdn doc...

That would be an area I would look at to see if there is contention.  Keep in mind that each incoming request is a thread.  if .NET is starting, it's going use alot of them quickly if your server is busy.

 

I've been working with Tim on this off and on for a few weeks.  We increased his maxWorkerThreads to 100 (the default is 20) a while back.  It helped a little with keeping his site running longer, but not with startup times.

Here's a good link for that stuff:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt17.asp

My theory is that there is so much cache to load for DNN when his app starts that there just isn't enough CPU to get it done, and there is probably some contention also when several of his portals try to load simultaneously.  His server is definately processor bound during startup though, especially if traffic is allowed to get to it.

Did you know that when the app is loading that each Language .resx file that a new XML Document is created and transferred to a hashtable for each one, then placed into cache?  This can 10 or so .resx files per page.  Now imagine several different pages starting at the same time, plus loading the cache for portal settings and tab settings.

By the way, I have seen on a couple of installs where turning off caching totally brings the server to it's knees, and the application ends up recycling over and over because it's in a deadlocked state, so don't try that unless you can get at the database and put it back.

 

---

Thanks for the idea as well as the "out of box" thinking!  The issue is that I don't want to stop or start the windows firewall, I simply want to enable/disable a firewall exception.  My OP had a link to the Windows ICS API to do this, however, I'm not well versed enough to pick up on it and write an little program without spending a ton of time trying to think of how.  Right now, I'm spending a ton of time trying to figure it out but have no such luck yet.   Check out the URL, who knows...  :)