As we all know, it is not easy to implement an application that runs 24*7. One of my projects once persisted for more than 20 hours under violent load and still died heroically. Fortunately, ASP.NET and IIS provide us with some easy facilities that allow us to easily build super stable .Net applications. However, what is a bit unpleasant is that the configuration methods under Windows 2000 (versions below IIS6.0) and Windows 2003 (IIS6.0) systems are different.
Let’s talk about the windows 2000 system first. Those who are familiar with ASP.NET should all know the machine.config file. It is stored in the %WindowPath%Microsoft.NetFramework%.NetVersion%CONFIG directory. Use any text editor (of course the most popular one is "Notepad") to open the file and find the <processModel...> section. ASP.NET controls the ASP.NET service process (aspnet_wp.exe or w3wp.ext) based on the settings in this section. The ASP.NET application code we wrote runs in this process space. If you are using Framework 1.1 you will see more than n properties in this section. We are concerned with the following three, followed by the equal sign are their default values:
timeout="Infinite"
idleTimeout="Infinite"
memoryLimit="60"
You can't see them under Framework 2.0, but you can add them manually.
Let me translate the meaning of these three attributes. After running continuously for the time specified by timeout, restart the ASP.NET service process. The default value of timeout is infinity. You can reset it in the format of "HH:MM:SS" , for example, timeout=24:00:00 means restarting after 24 hours; If no one accesses within the time specified by idleTimeout, restart the ASP.NET service process. The default value of idleTimeout is also infinite, and the setting method is as above; if If the percentage of memory used by the ASP.NET service process to the total system memory exceeds the amount specified by memoryLimit, the ASP.NET service process will be restarted.
Understand, through the cooperation of these three attributes, the service process can be restarted without knowing it, so that our application can continue to run. When I say this, careful readers may have discovered the problem. When the service process is restarted, the client's session will inevitably be lost and the user's operation will be interrupted. How can we achieve "God does not know and ghosts do not know"?
This problem does exist, but its impact can be minimized or even eliminated completely by the following measures:
First, we can set idleTimeout to a reasonable value, usually I will set it to 1.5-1.5 of the session timeout setting. 3 times. Set the timeout to the upper limit that the program can persist. I usually set it to 24 hours. This will force the service process to restart when it is idle. Since there is no session at this time, it is impossible to interrupt the user's operation. This setup is very effective in an office environment of small and medium-sized enterprises, because there is basically no access after hours.
Of course, the above method has great limitations and can only work in specific situations. If someone continues to access or restarts when the memory exceeds the limit, the user's operation will still be interfered with. An ultimate solution is to save the session state in a separate process. On ASP.Net this is also possible with simple configuration.
Source: BLOG recording room