Asp.Net Worker Process Recycling

If a Web application contains code that causes problems, and you cannot easily rewrite the code, it might be useful to limit the extent of the problems by periodically recycling the worker process that services the application. You can accomplish this by using what is known as Worker Process Recycling. Worker process recycling is the replacing of the instance of the application in memory. IIS 6.0 can automatically recycle worker processes by restarting the worker process, or worker processes, that are assigned to an application pool. This helps keep problematic applications running smoothly, and minimizes problems such as memory leaks. You can trigger the recycling of the worker processes assigned to an application pool by using worker process recycling methods that are based on elapsed time, the number of Hypertext Transfer Protocol (HTTP) requests, a set time of day, and two kinds of memory consumption, in addition to recycling on demand.

To configure all the above settings, go to the Properties window of the application pool in which your Web application is running using the IIS manager. Using the Recycling, Performance, and Health tabs in the Properties window, you can specify values for the above settings. Navigating to the Performance tab in the Properties dialog box of the DemoAppPool results in the following output.



When you set the recycling of worker processes using IIS manager, you also need to take the state management strategy of your ASP.NET application into consideration. Because every time the worker process is recycled, the ASP.NET state information will be lost rendering the application in an invalid state. One alternative to overcome this issue is to maintain state data external to the worker process, such as in a database. However, moving data to an external database to allow recycling can affect server performance in the following two ways:

• Performance is reduced because of the added data management that is needed to move the data between the application and the database.
• Recycling flushes any in-process data caches, so the caches need to be rebuilt.

If you have an application pool with applications that depend on state data, you must decide whether or not to recycle the worker processes that are assigned to that application pool. If you store state in the same process as that of IIS, and you don't want the state information to be lost, you must not recycle a worker process using the application pool configuration settings.

Encryption Sections of Web.config

Configuration files are just great ; they let you configure the website .It's a great place to store the information which you are going to be using throughout the application and which is not changing.

You can easily encrypt sections of web.config in ASP.NET 2.0. In the code below I have encrypted the ConnectionStrings section of web.config.

Configuration config = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
ConfigurationSection configSection = config.GetSection("connectionStrings");

if (configSection.SectionInformation.IsProtected)
{
configSection.SectionInformation.UnprotectSection();
config.Save();
}
else
{
configSection.SectionInformation.ProtectSection("DataProtectionConfigurationProvider");
config.Save();
}

.NET Framework 2.0 introduces a protected configuration feature that you can use to encrypt sensitive configuration file data by using a command line tool. The following two protected configuration providers are provided although you can also implement custom providers.

• RSAProtectedConfigurationProvider : This is the default provider and uses the RSA public key encryption to encrypt and decrypt data.
• DPAPIProtectedConfigurationProvider : This provider uses the Windows Data Protection API (DPAPI) to encrypt and decrypt data.

You can also writing connection string dynamically:

Configuration config = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
ConnectionStringsSection conSection = (ConnectionStringsSection)config.GetSection("connectionStrings");
conSection.ConnectionStrings["SQLConnectionString"].ConnectionString = "NewConnectionString";
config.Save();

[Please note that when you write to a web.config file the application restarts which means all the session and application variables are lost.]