I have written a few articles about this here, but wanted to expand on it with this specific lab. In this lab you will:
- Install the Application Initialization feature
- Utilize ASP.NET MVC website created in Lab 1 and Lab 2 hosted here
- Configure Application Initialization for the CSharpGuitarBugs website
- Learn about the ASP.NET warm-up request
- Learn about ASP.NET temporary files in Lab 28
I got lots of the contents of this lab from here.
Install the Application Initialization feature
Q: What issue does this module attempt to resolve? A: When changes are made to the ASP.NET application or certain configuration changes are made, the temporary ASP.NET files need to be recompiled. The first request to the ASP.NET file is what triggers the compilation. Depending on the complexity of the web application, this request can take some time. This module makes the first request to the web site after a recycle or restart and warms up the site, this avoids having a customer or visitor doing it.
Install the Application Initialization using the WPI as per these instructions, here up to Figure 2. The website in the that article is referring to another site, the source for that site can be downloaded here.
If you have not already accessed the CSharpGuitarBugs website, then open the task manager and you will notice that there is no W3WP process running for the CSharpGuitarBugs website. If you have already accessed the site, there will be a W3WP process, see Figure 3, execute an IISReset from a command prompt, shown in Figure 1, and notice that the W3WP process is removed from task manager.
Figure 1, execute an IISReset to stop W3WP processes
Using the configuration editor, at the server level, as shown in Figure 2, set the startMode for the CSharpGuitarBugs application pool to AlwaysRunning.
Figure 2, setting startMode as AlwaysRunning for IIS, AlwaysOn
Close the Collection Editor window and press the Apply button in the Action pane to apply the settings. NOTE: before you press the Apply button, click on the Generate Script link. This is a cool feature to view the PowerShell, C#, AppCmd, etc. for making the same modification. You will then see the W3WP process running for this web site in Task Manager, as illustrated by Figure 3.
Figure 3, AlwaysRunning W3WP process
Q: What are the advantages of having the W3WP process always running? A: By default, a worker process will terminate if there is no access to it within 20 minutes. That means that the process and the memory which it consumes is de-allocated and can then be used by other processes. If the W3WP process is not running, when a request is made to the website, WAS (discussed in Lab 6) will have to spin up the process before the request can be responded to. Having your process AlwaysRunning will keep the W3WP process running without shutting it down after an time period. In IIS 8.5, instead of terminating the W3WP process after 20 minutes, you can now suspend it. Read here for more information about that.
Next, use Process Explorer, downloadable from here to look at the properties of the W3WP process. Figure 4 illustrates that there is no .NET Assemblies tab, which signifies that there is no managed code compiled or contained within the process yet.
Figure 4, Process Explorer showing no .NET Assemblies
Take a quick look at the compiled ASP.NET files in the C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root directory. You should not see any compiled ASP.NET files for this web site because it has not been accessed.
Access the CSharpGuitarBugs web site and then refresh the W3WP process in Process Explorer. Notice, Figure 5, that there is now a .NET Assemblies tab and that you can see the modules that were compiled.
Figure 5, temporary ASP.NET files created with first access, warm-up
Take another look at the compiled ASP.NET files in the C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root directory. You should now see some compiled ASP.NET files, similar to Figure 6. Notice that the assemblies reported via Process Explorer have a matching .dll in the Temporary ASP.NET Files folder.
Figure 6, Temporary ASP.NET files folder
Now, open Task Manager again and find the W3WP process for the CSharpGuitarBugs website and note the process id (PID). Execute and IISReset, as shown previously in Figure 1, and notice the W3WP process is recycled and a new W3WP process, with a different PID, is started automatically.
Q: If nothing changes, will the ASP.NET pages be recompiled after an IISReset? A: No, if nothing changes, after a recycle, then IIS is smart enough to know that the files do not need to be recompiled and the request is responded to using the already compiled ASP.NET file, for example the App_Web_ezxbpqls.dll file. You can confirm this by looking at the Date Modified on the temporary file. Does it change after a recycle?
So the real value of Application Initialization is to make the first request after changes are made to the application that require the ASP.NET page to be recycled, like a deployment of a new release or a configuration that requires a recompile, like setting debug=false/true, for example, discussed here.
To complete the configuration of Application Initialization, again open the Configuration Editor at the server level and modify the applicationPool, path and preloadEnabled values as shown in Figure 7.
Figure 7, Application Initialization required configurations
Close the Collection Editor and apply the changes by clicking the Apply link in the Action pane.
Manually stop the CSharpGuitarBugs application pool, as show in Figure 8 and delete the existing Temporary ASP.NET Files. This is done to make sure there is no W3WP process running and that there are no existing temporary ASP.NET files insuring that when we start the process again, we are certain Application Initialization triggered the compilation.
Figure 8, stop the website and application pool
The expectation is that now that Application Initialization is configured, as soon as I start the application pool again, that a warm-up request is sent and the ASP.NET temporary files are compiled and ready for the first real request from a user or customer.
You might consider executing an IISReset as discussed previously, Figure 1. Additionally, if the warm up request does not happen, make sure you have installed the Application Initialization role, as per these instructions and mentioned at the beginning, as it is possible to make the preceding confirmations without having the module installed. See Figure 9.
Figure 9, installing the Application Initialization role