Web Application Cache – How to empty the Cache by recycling the App. Pool

Most if not all Web-based Applications maintain a concept of Sessions (per-user) or Application (system-wide) caching, so common variables and attributes are not being loaded from storage (such as from Dynamics CRM, Config File or other Database) multiple times and leading to lower performance.

There are various options on how this Session or Application Cache is stored, but probably the most common is keeping the cache held in memory within the Web Server.

This means the cache lives within the Web Server Process on the Server, typically referred to as the IIS Service or the W3WP.EXE Process when viewed from Windows Task Manager:

All those cached attributes are in that ‘w3wp.exe’ somewhere!

This explains why the Memory Usage for the W3WP.EXE Process may grow on a Web Server, as the various cached attributes or sessions are being held in-memory by this process.

To empty the cache, we have several options:

Restart the Server, this restarts everything and so the Web Application is forced to reload from the ground up. This definitely wipes the slate clean but also takes down our Web Application for 5-10 minutes whilst the Server reboots, and so is far from ideal!
- This does what it says on the tin, so to do this, we simply restart Windows on the Server.
Restart the Process, this unloads and then reloads the process running our Web Application and so forces the process to reload any cached variables. This still takes down our Web Application, but only for around 5-10 seconds rather than minutes – however it also takes down ALL the Web Applications that were running in this process, and so may impact several Web Applications running on that Server.
- To do this, we can open a Command Prompt on the intended Server and run a command for ‘IISRESET’ – this ‘reboots’ the main Web Hosting Service on the Server.
Recyle the App Pool, behind the scenes for the Process running our Web Applications is a series of App Pools. These App Pools run within the Process and do the heavy lifting of responding to requests for our Web Application – however each Process can host however many App Pools, and so restarting a single App Pool then only affects the Application(s) using that particular App Pool. In this way, restarting or recycling a single App Pool gives us the ability to restart a single Web Application rather than ALL the Web Applications running on that Server.
- To do this, we open Internet Information Services on the Web Server
- Expand the Server to see ‘Application Pools’ and ‘Sites’ – click on Application Pools
- Right click on the correct Application Pool and then click Recycle
- This will reload all the instances of the Application within that Pool, and so empty the cache. (the application will then reload the cache when the Web Application is next loaded)

Recycling a particular Application Pool within Internet Information Services

How do we know which Web Applications are running in which Application Pool?

We can either highlight the Application Pool within Internet Information Services and then click the ‘View Applications’ option on the Right-hand side – this will then show a list of Applications running within that Application Pool.

Alternatively we can expand the Sites area of Internet Information Services to then view the different Websites/Applications that the Server is hosting.

We can then highlight any one of these Web Applications to show an option for ‘Advanced Settings..’ on the right-hand side, clicking this option will then show advanced configuration settings for the website, including the ability to view and change the Application Pool that is hosting the Site.

Reviewing the Application Pool in use for a particular Website in Internet Information Services

Is the Web Application Cache always held in the Application Pool / IIS Service?

No – occasionally we will use a separate Session Server Process or even SQL Server to retain the Application Cache and/or Session Cache; however this far less common for smaller Web Applications.

(although this is required in some form for redundant or ‘cloudy’ Web Applications that may span several Web Servers and therefore span several IIS Services, and so must manage a separate Cache/Session storage method)