34 msdn magazine .NET Framework
Better Application Performance
Application performance is a constant focus area for the .NET
Framework team. In this release, we responded to feedback on the
garbage collector and signifi cantly improved ASP.NET app startup.
ASP.NET App Suspension Th is feature is one of the top highlights
of the .NET Framework 4.5.1 due to the signifi cant performance gain
it provides, particularly for shared hosting scenarios where site
density and startup latency are critical. ASP.NET App Suspension
will enable shared hosters—either commercial Web hosting com-
panies or enterprise IT systems—to host many more ASP.NET Web
sites on a server with faster app startup time.
ASP.NET App Suspension depends on IIS Idle Worker Process
Page-Out, which is a new IIS feature in Windows Server 2012 R2.
IIS Idle Worker Process Page-Out introduces a new “suspended”
state in addition to the existing “inactive” and “active” states for Web
sites. Th is new “suspended” state releases critical resources used by
the site for other sites to use, specifi cally CPU and memory, while
still enabling the site to be resumed quickly.
Figure 6 shows the state transitions of ASP.NET sites using App Sus-
pension. A Web site starts in the inactive state. It’s loaded into memory
and transitions to active with the fi rst page request. Aft er a period of idle
time, the site will be suspended, per application pool confi guration (bit.ly/
1aajEeL). Upon subsequent requests to the site, it can quickly return to the
active state. Th is cycle can happen many times. Up until now, sites would
get terminated and become inactive aft er a certain amount of idle time.
No code change is required to use this new feature. ASP.NET App
Suspend is enabled automatically by confi guring an IIS application
pool for “Suspend” on Windows Server 2012 R2.
Earlier I touted a “signifi cant per-
formance gain” achieved with this
feature, and I’d like to back this up
with some numbers coming from
our performance labs. We conducted
extensive performance experiments
to measure the startup time gain for
“resume from suspend” compared
to “start aft er terminate.” We did these experiments on a machine
under signifi cant request load, accessing a large number of appli-
cation pools, with the intent of recreating a “shared hosting”
environment. The results showed a 90 percent reduction in the
startup time for sites that were accessed aft er suspension. We also
measured the improvement to site density. We were able to host
about seven times more ASP.NET sites on Windows Server 2012 R2
when ASP.NET App Suspension was enabled. Figure 7 shows the
results of these experiments. More insights into these experiments
can be found in the “ASP.NET App Suspend – responsive shared
.NET Web hosting” blog post at bit.ly/17fI6dM.
Multi-Core JIT Compilation Enhancements Multi-core JIT
compilation is now enabled by default for ASP.NET apps. Perfor-
mance measurements show up to 40 percent reductions in cold
startup time with multi-core JIT enabled. It provides startup
benefits by performing JIT compilation on multiple cores, in
parallel to code execution. Under the covers, multi-core JIT was
extended to support dynamically loaded assemblies, which are
common in ASP.NET apps. Th e additional support also benefi ts
client apps, where multi-core JIT remains an opt-in feature. More
details about the multi-core JIT feature can be found in the related
.NET Framework Blog post, “An easy solution for improving app
launch performance,” at bit.ly/RDZ4eE.
On-Demand Large Object Heap (LOH) Compaction LOH
compaction is an important requirement for some scenarios, and
it’s now available in this release. First, a little background informa-
tion, as LOH might not be familiar to you. Th e garbage collector
stores objects larger than 85,000 bytes in the LOH. Th e LOH can
get fragmented, and in some cases this
might lead to relatively large heap sizes or
even OutOfMemoryException exceptions.
These situations, although rare, occur
because there aren’t enough contiguous
memory blocks available in the LOH to
satisfy an allocation request, even though
there might be enough space in total.
With LOH compaction, you can reclaim
and merge smaller unused memory
blocks, making them available for larger
allocations, which makes better overall
use of machine memory. Although this
idea sounds appealing, the feature isn’t
intended for common use. Compacting
LOH is an expensive process and can cause
long pauses in an application, so it should
only be deployed into production after
Figure 5 Visual Studio 2013 Autos and Intermediate Windows analysis and testing.
Figure 4 Visual Studio 2013 Tasks Window