IIS Application Pool Recycling Settings

Recently I had chance to look into IIS's capability to auto recycle app pool. Because one of our web app was hogging the whole server claiming all the memory it can get when it working at its peak. 

When hosting applications on IIS (Internet Information Services), managing application pool recycling is crucial for ensuring stability and performance not only on the target app, but for whole server. Recycling helps refresh the application environment by periodically restarting the worker process to prevent memory leaks, releasing un-wanted memory, resource locking and unexpected issues. 

Recycling Settings in IIS App Pools

Recycling settings are per App Pool. There fore you can configure each pool differently. These settings can be found in Advanced Setting dialog. Right click on the desired Application Pool and go to "Advanced Settings" dialog.

There are lot of "Advanced Settings" therefore, you might have to scroll down to see these settings, they are at the right below the dialog.

"Disable overlapping recycle", "Disabling Recycling for Configuration Changes" (blog done for this), "Generate Recycle Event Log Entry" are settings which are relate to recycling but not something allow us to control recycling times. So we skip them for bit.

1. Regular Time Interval (Fixed Interval Recycling)

• Setting Name: Regular Time Interval (in Minutes)

• Default: 0 - means application pool will not recycle regular time intervals

• Description: Automatically recycles the worker process after a specified time interval.

• Use Case: Useful for applications that need periodic refreshing to prevent performance degradation. However, setting this too frequently can disrupt user sessions. For example you can set your application pool to restart every 12 hours (720 minute), when you know these 12 hour intervals are not its peak times.

2. Specific Time(s) (Scheduled Recycling)

• Setting Name: Specific Times

• Description: Allows recycling at predefined times during the day.

• Use Case: Ideal for scheduled maintenance windows. For example, in above screen shot we recycle application pool at 00:05 mid night, then 3:05AM (which is probably after maintenance job), then 6.30AM (just before users try to access), 12.45PM (mid day when traffic is low when every one at lunch), 5.30PM (when users logging off), 7PM (before we kick off maintenance tasks).

3. Memory-Based Recycling

a) Private Memory Limit

• Setting Name: Private Memory Limit (KB)

• Description: Recycles the worker process when its private memory consumption exceeds a specified threshold.

• Use Case: Helps prevent excessive memory usage due to memory leaks in applications. For example, if an app is expected to use a maximum of 2 GB, setting a limit slightly above (e.g., 2.5 GB) ensures it gets recycled before causing server slowdowns.

b) Virtual Memory Limit

• Setting Name: Virtual Memory Limit (KB)

• Description: Recycles the worker process when its virtual memory usage exceeds a specified limit.

• Use Case: Less commonly used but can help control applications with excessive virtual memory allocations. Similar to private memory limit, but include shared memory space as well.

4. Request-Based Recycling

a) Request Limit Recycling

• Setting Name: Request Limit

• Description: Recycles the worker process after processing a specified number of requests.

• Use Case: Useful for high-traffic applications where a certain number of requests may cause the application to degrade. For example, if an API handles millions of requests daily, recycling it after every 500,000 requests can help maintain performance.

There are other settings such as "Idle Time" (cause app pool to terminate or suspend when there are no requests), "CPU Limit" which can also effect the application pool recycling/terminating behavior, but we will discuss this in a separate blog.

Best Practices for Application Pool Recycling

Although above helps your recycle the claim back any un-used or over used memory, this process need to be done with care. Because Frequent recycling can disrupt user sessions and degrade performance.

Always try to recycle during off-peak hours. This will minimize disruptions to user session. 

There are settings in "Generate Recycle Event Log Entry" section which allows your to control what recycle action should be logged in Windows Event log. Use this to your advantage and track when is the actual recycling is happening by monitoring the logs for period of time. This will give more insight and use this insight to adjust the recycling settings.

IIS Max Allowed Content Length

Last week one of our third party integrator who is using our web api has asked what is the maximum number of ids they can query.

In this api they use, they send (Post) array of ids and in return, API provide status of those records. So they wanted to know what is the maximum limit they can send in the ID array.

I didn't had a answer straight away. That got me thinking.

Ids are in body, because it is a post request. So "maxQueryString" limit will not comes into play as far as I can see. 

I have done bit of Googling and found out there is a setting in IIS, which filter requests. It was called "maxAllowedContentLength". As I found out this is a security setting which limits some one sending huge requests. This setting can be found in system.webServer/security/requestFiltering section. If you looking in the web.config file you can see it in following section:

This setting is there to prevent DoS attacks.

Value in this setting is in bytes. Default value seems to be 30,000,000 (30 million) bytes, which is approximately 28.6 MB.  Most of time in production web servers, we tends to go much lower limit.

When you consider 28.6 MB, it can accommodate large number of IDs for our supplier, but on the other hand in order to full fill that request, back end (data stores) must work very hard. There fore, I have advice not to send too many Ids in there request and split their request to several sub request (paging) in order to prevent data store servers overwhelming. 

If you exceed "maxAllowedContentLength" limit, you will get HTTP 404.13 - Request Entity Too Large.

Prevent App Pool recycle when web config changes

We all know when we need to recycle and get web app restarted we can edit the web.config file. Sometime we(developers) even do dummy change to force it restart.

But what if you don't want to recycle it, but want to update the web.config file anyway. For example I had a situation where I want to update the web.config file, but didn't wanted to recycle/restart the web app immediately, because users were using it heavily. I just needed to do the web.config update now and restart the web app later (out of working hours).

That's when I heard the setting called - "Disable Recycling for Configuration Changes".

This setting can be found in "Advanced Settings" section of an app pool. So this only effective to one app pool at a time.

Default value for this is "False".

Setting this to true will cause app pool to NOT to restarts/recycle when web.config changes.