IIS 8.0 Application Initialisation reduces response time for SharePoint 2013
Using IIS 8.0 Application Initialisation to ensure that SharePoint 2013 responds quickly after application pools are recycled
Firstly it's worth noting that I'm not a Systems Administrator but as a SharePoint Developer I do need to understand a bit about web administration. Having been in the SharePoint field for 5 years now, I know how painful it is to wait for an IIS App pool to ‘wake up’ after it has recycled. I’ve learned to be patient and wait, wait and wait a bit more. This happens a fair amount because every time I want to test a change in the code-behind I have to recycle the relevant application pool. As we all know, patience is not a strong suit of most end-users, and no one can blame them – time is money, and waiting long time for a page to come back is frustrating. And when it comes to SharePoint, waiting is guaranteed.
So, what could we do to speed up the response time after an application pool is recycled? There are different approaches that could be taken. Some of them include a warm-up script that is registered as a scheduled task and is executed sometime in the early hours after the application pool is recycled. Or SharePoint Timer Jobs that do the same. I don’t think it is necessary to go into the details of why an approach like this is not reliable, but some of the points ‘against’ would be: what happens if the IIS application pool is recycled again after the warm-up script runs, or the schedule changes, or simply the company policy prohibits usage of custom scripts to be executed daily on their production servers?
Recently my colleagues pointed out a new feature of IIS 8.0 called Application Initialisation, also available for IIS 7.5 as additional module (details here). We decided to give it a go and see how it could be used with SharePoint, and there is no better place to test the approach than our brand-new Windows 2012 server running SharePoint 2013.
1. Initial measurements
In order to understand if and how this approach can improve the performance of our environment, I did some initial measurements on the response time of 'start.aspx' page. For this purpose I used Fiddler which showed that the response time of the start page after IISRESET is approximately 34 seconds. This is not great, but this provided us with the baseline to target the improvements against.
Once this was done I was ready to proceed with the configuration of the environment.
Note: The approach described below requires changes to configuration files. It is highly recommended to create a backup of those files before performing the changes.
2. Enable ‘Application Initialisation’ feature for IIS 8.0
Open the Server Manager dashboard on your Win 2012 server and select ‘Add roles and features’, navigate through the wizard until the ‘Server Roles’ selection appears, scroll down to Web Server (IIS)‘, expand ‘Web Server’, ‘Application Development’ and select ‘Application Initialization’
Note: If your server is running IIS 7.5 you will need to install an additional module, not through Roles and Features wizard.
3. Configure SharePoint web application - applicationHost.config file
To enable Application Initialisation for an application pool, first you have to modify its settings under ‘applicationHost.config’ file. This file is the root configuration system for IIS 7.0 and above, and contains definitions for all sites, application pools, virtual directories and so on. applicationHost.config can be found under %WINDIR%\system32\inetsrv\config. Application pool settings are located under system.applicationHost > applicationPools. Each application pool is in its own ‘add’ element, with the ‘name’ attribute being the name of the application pool. In our case it is called ‘SharePoint – 80’. Now we need to add new attribute ‘startMode’ with a value of ‘AlwaysRunning’:
Then find the corresponding ‘site’ element inside the ‘sites’ element, again ours is called ‘SharePoint - 80’. In its child ‘application’ element change the ‘preloadEnabled’ attribute to ‘true’.
This property enables “fake” request to the application when it starts up.
The combination of both properties ensure the application is always running and will receive the fake request whenever the server is restarted or the service recycled. It is recommended to apply the changes above for the other application pools as well, especially the ‘system’ application pools SharePoint uses, such as Security Token Service, to avoid a delay in the response when the SharePoint site is trying to communicate with them.
4. Configure SharePoint web application - web.config file
Next we have to configure the specific web.config file for the SharePoint web application. SharePoint has a web.config file for each web application under inetpub\wwwroot\wss\VirtualDirectories\[port number]. We want to update web.config to tell IIS what page to hit when the fake request is made. The changes we are making are under “system.webServer” configuration section.
According to IIS settings there is an additional attribute named ‘remapManagedRequestsTo’. This attribute keeps the location of a file to provide while waiting the ‘/’ to start responding. Unfortunately, this property doesn’t seem to be considered in SharePoint.
5. Verifying the result
The first thing to note after the changes above have been applied is that the w3wp.exe process instance starts right after IIS has been recycled. This can be easily seen in Task Manager.
Using Fiddler again I checked the response time of "start.aspx" page after making the changes, and it came down to 12 seconds:
This still doesn’t beat the under 1 second response without recycling the pool, but we all know that SharePoint does a bunch of things behind the scenes - content caching, user authentication and so on. That said, reducing the response time from 34 to 12 seconds can be considered a pretty good result.