ASP.NET App Suspend – responsive shared .NET web hosting
This post introduces ASP.NET App Suspend, which is a game-changing feature in the .NET Framework 4.5.1. It radically changes the user experience and economic model for hosting large numbers of ASP.NET sites on a single machine. This post was written by Rich Lander, a Program Manager on the .NET team.
Sharing can be hard. In my early days, I had trouble sharing lego bricks. Now, it’s web hosting. I have to choose between shared and dedicated hosting for the sites I put up. That choice is not always easy, since the cost and level of service can be so different.
What if I didn’t have to share my legos. Wouldn’t that be nice? It’d be even nicer if my cheaply-hosted web sites started up (much) faster. That’d be really nice. This post will tell you about a set of changes we’ve made in Windows Server 2012 R2 and the .NET Framework 4.5.1 to make that a reality. Note that I briefly mentioned this feature in an earlier post on the .NET Framework 4.5.1.
Suspend is the new terminate
ASP.NET App Suspend is a new feature in the .NET Framework 4.5.1 that makes ASP.NET sites much more responsive and enables you to host more sites on a single server. It is very well suited for commercial web hosters, like Windows Azure Web Sites, and Enterprise IT web hosting. It also benefits other scenarios, which I’ll touch on later.
ASP.NET App Suspend is built on top of another new feature in Windows Server 2012 R2, called IIS Idle Worker Process Page-out, which is a new addition to Internet Information Services. ASP.NET App Suspend is really the .NET implementation of the IIS feature. The .NET team has done the work so that you can use this new feature of IIS with the simple flip of a switch. Really!
The best way to think of this feature is that it’s the cloud scale version of the app suspend (AKA tombstoning) features that you see used in Windows Phone and Windows Store apps. The implementation and characteristics in Windows Server 2012 R2 are not the same as client Windows, however, the same basic premise applies: run the app once and then it is much faster to start subsequently. This feature takes advantage of a number of services that have been in Windows for a long time, but have never been available for Web applications until now.
ASP.NET App Suspend is a self-tuning mechanism for web hosting, a little bit like CLR GC generations (if you squint). The addition of suspend establishes three states that a site can be in on a given machine. You can see the three states in the diagram, below.
All sites start out as inactive. As sites are requested, they are loaded into memory, become active, and respond to page requests. After sites have been idle, as determined by the timeout setting, they will be suspended. Suspended sites effectively lose access to the CPU, making CPU cycles and most of the memory they were using available for requests to other sites. However, they are kept in a state – this is the new suspended state – by which they can be resumed very quickly and respond to traffic again.
In a shared hosting environment with ASP.NET App Suspend enabled, we would expect to see a similar number of sites active at any one time, as compared to Windows Server 2012, and many additional sites in the suspended state, after the server has been responding to requests for a while. The addition of the suspended state, which is a very low-memory state, enables ASP.NET to host many more sites on a given machine.
With this three-state model in place, Windows Server 2012 R2 can deliver consistent performance for many more ASP.NET sites, hosted in a shared hosting environment.
Serve More Sites, FASTER
The following video demonstrates how to enable ASP.NET App Suspend, and how it performs after an idle time-out. It contains a head-to-head comparison between “launch from terminate” and “resume from suspend”. The results speak for themselves. Check out the video (2:19 runtime).
ASP.NET App Suspend really helps
Earlier this year, the IIS perf team tested the performance of the new Suspend feature. They compared “resume from suspend” and “launch from terminate” on a machine that was under load, which they thought represented a realistic scenario. The results were striking.
The value of app suspend is two-part. It helps with both site density and startup latency. I’ve already covered the mechanics behind startup latency. Sites startup faster because they are suspended in a “ready to go” state.
Site density is also massively improved. It isn’t a question of how many sites you can register for a single app pool. That is presumably unchanged. It is a question of how many sites that you can have in a “ready to go” state at once. For Windows Server 2012, that’s limited to how many sites you can actually hold in memory at once. For Windows Server 2012 R2, it’s the combination of sites that are actively loaded and the much greater set that are suspended. Suspended sites still do take some amount of memory, but a small fraction of what an active site would take.
We conducted an experiment to demonstrate how much ASP.NET App Suspend improves density. We ran the experiment on Windows Server 2012 and Windows Server 2012 R2. In both cases, we loaded up the machine (same machine) with sites until it hit 80% memory utilization, as measured by Windows perf counters. 80% is a good base utilization number, since it allows for memory spikes while the apps are running.
For Windows Server 2012, we disabled the terminate timeout, and then loaded sites, 100 at a time, until we hit 80% memory utilization. For Windows Server 2012 R2, we set the suspend timeout at 1 min, and then loaded sites every minute, 100 at time, until we hit that same memory utilization. Naturally, those sites would all suspend. We were able to load 300 sites on Windows Server 2012 and 2100 sites on Windows Server 2012 R2, with suspend enabled. That’s a 7x increase!
We also conducted another experiment, where we measured startup time. We had 1000 sites registered on the machine, which were an equal number of duplicates of four different .NET site packages (ex: DotNetNuke). We then hit each one of those 1000 sites in a round-robin fashion, in order to blow disk, memory and SQL caches (realistic effect for shared hosting). We took measurements, and averaged them for each site type, for both the cold startup and suspend cases. We also had another set of sites on the machine that we were hitting at the same time to create significant load on the machine. As a result, the numbers we recorded are biased towards worst case, for both cold start and resume for suspend scenarios. In many cases, you will see better numbers than ours.
You can see the density and startup improvements that we observed in our lab in the chart below, with the set of apps that we chose.
We went through significant effort to create a good “at load” scenario to demonstrate the value of ASP.NET App Suspend, for the charts above. This will be difficult for you to do on your own machine. It will also mean that you won’t see startup numbers as bad as the ones above on an idle developer machine. To that end, we created another set of numbers, just for DotNetNuke, at idle. You can see that the gap remains just as significant.
For a feature that requires zero code changes to adopt, I’d say that’s pretty great value!
Our performance tests were conducted on a machine with the following specs:
- Intel Xeon L5630 2.13 Ghz – 4 cores
- 32GB RAM
- HDD for sites
- SSD for page file
How to enable and monitor ASP.NET App Suspend
It is really easy to enable ASP.NET App Suspend. It’s a new setting in IIS configuration, available on each application pool. I posted a blog post on the ASP.NET team blog that explains how: Enable and monitor ASP.NET App Suspend on Windows Server 2012 R2. If you are familiar with IIS configuration, here’s the one screenshot that you’ll need.
This post focused on the shared hosting usage scenario, however, there are a few other scenarios that can benefit from ASP.NET App Suspend.
- Shared hosting (commercial hosting or enterprise IT) Companies selling or taking advantage of shared hosting can pack many more sites on a given machine, while providing much more responsive site experience.
- Switch to shared hosting Web site owners can take advantage of low-cost shared hosting while delivering the responsive experience that they want.
- Hot spare for large sites Large high-traffic sites can maintain spares in suspend, ready for when one of the servers behind a load balancer goes down (planned or unplanned).
- Disaster recovery Large high-traffic sites can maintain spares in suspend in a backup datacenter, ready for when the main data center goes down or otherwise becomes inaccessible.
ASP.NET App Suspend is a new feature for ASP.NET, available in the .NET Framework 4.5.1 on Windows Server 2012 R2. It delivers much better startup responsiveness for sites that do not get consistent traffic and would otherwise not be kept loaded in a responsive state at all times.
In our lab, on our hardware, we found that that startup time, of “resume from suspend” as compared to “start after terminate” dropped by 90% and that site density increased by 7 times. Those are great improvements. Your mileage will vary, however, we expect that you will see great improvements if your site is a lower-traffic site or fits one of the usage scenarios described above. Our experiments were conducted with the page file on an SSD, however, performance is still great if you use a traditional hard-drive.
Please try out the feature. It is very easy to opt in and out. You can learn how to enable and monitor ASP.NET App Suspend in another post on this topic on the .NET Web Development and Tools blog. How did ASP.NET Suspend work for you?