WinServe "maching.config" settings

We have several DotNetNuke sites running and have noticed some peculiar behavior over the past few months.

Very frequently (especially during the day), we will see instances in our DNN Log where the appliation simply starts up. While at first we had thought it was simply the application shutting down and restarting due to inactiviy (typical ASP.NET configurations), we found many instances where there was no log of the application_shutdown process, ONLY an application_start process in the log.

So, I did some digging on MSDN and found that ASP.NET can be configured (in “maching.config”) to force the App Worker process (ASPNET “aspnet_wp.exe” on win2k, NETORK SERVICE “w3wp.exe” on w2k3) to start a NEW process under certain conditions (such as certain amount of memory, cpu utilization, etc.). These parameters are located in the “processModel” node of the “machine config”:
requestQueueLimit, memoryLimit, and shutdownTimeout.

My question is this: Can you tell us if the “processModel” is enabled on our Windows WebServers? And, if so, what are the parameters (above) configured as?

The reason I as is because if the requestQueueLimit, memoryLimit, and shutdownTimeout parameters are set very low, our applications will continue to restart (losing application data, session data, etc.) throughout our customer’s browsing experience.

If these parameters are NOT configured on our WinServers, then is it possible that a (or some) applications are causing an “ungraceful” shutdown of the IIS worker processes throughout the day?

Second question: How are the virtual directories (domains) isolation levels set? Are all virtual directories set to share worker processes? Or, are each set to “High (isolated)” worker process? (i.e. is each virtual directory running it’s own aspnet_wp.exe (or on w2k3: w3wp.exe) process?

If we are all sharing the same IIS worker process, then if someone’s application causes an “ungraceful” shutdown of the worker process, it will cause a shutdown of ALL AppDomains on the server… This could be what is causing what I see in my logs…

Any thoughts Stephen or others?

Thanks.

Bump.

We seperate sites by app pools, which gives each of them a different ASP.NEt Process. I don’t really have the details on me now as I am on vacation, I will dig them up when I get a chance.

requestQueueLimit, memoryLimit, and shutdownTimeout

RQL is 75000 I believe, Memory Limit is 60% of system memory, and Shudowntimeout is 2 hours, I believe.

About how frequently do you think Win11 hits 60% memory? Because our .NET app keep auto-recycling during the day. I’m wondering if memory is getting above 60% and this is causing asp.net to recycle all AppDomains, or could it be something else I should be looking into?

I’ll start looking at jodopulse when we notice a recycle, and see if it corresponds to any drastic memory utilization or Requests Queued…

Thanks for looking that up for us Stephen.

The ASP process is not recycling that much, but if you are using sessions they are probably dying, you need to use the state server to prevent that.

Stephen,

Am I correct in assuming from your reply that JodoHost has a “state server” running that we can “use”? Or do you mean that we can create a MSSQL state server db and use that? I’m sorry, I have only read limited information on Session State Server and was not quite clear on what you had intended…

I do believe that our primary problem is that session is being dropped, and would like to look into using state server to resolve this for a few domains. If you have instructions about getting our .NET apps to use the “state server” at JodoHost, can you point me in the right direction, or if you know of anyone else who is successfully using “state server”, can you let me know, maybe they can help me get this going on a test domain to try it out.

Thank you very, very much for the info!

– W.G.

Don’t know what “state server” is, but to have effective, efficient and scaleable session handling, you should use a table in your db to keep your session data in, and use a cookie to keep track of it’s record id (preferably guid) for the current user.

http://www.eggheadcafe.com/articles/20021016.asp

“State Server” is enabled.

Thanks for that Stephen, a valuable reference. I’d still recommend using stateless sessions for scalability. A cookie to keep the session guid and session data stored in a table. This precludes storing objects like datasets in session, but afaik that’s generally bad practice anyway.

what is the IP and port of the “state server” so I can use it? Is it “localhost (127.0.0.1)”? If so, what is the port? Thanks for the info and the article. Also, I found this article which goes a little more indepth:

http://www.awprofessional.com/articles/article.asp?p=31842&seqNum=3&rl=1

Ok, I got my app configured to use state server. Works good,and (so far) no (noticeable) lag or performance problems.

Thank you Stephen for pointing me in the right direction, and thank you for providing the state server!