Cluj München 1140km

Gânduri clujene din Bavaria

München - Munich - Monaco di Baviera

8. februarie 2014 13:37
by skorpionking
0 Comentarii

Microsoft .NET Framework 4.5.1 - Improved ASP.NET Web Site Performance

8. februarie 2014 13:37 by skorpionking | 0 Comentarii

Application performance is a constant focus area for the .NET Framework team. In this release, Microsoft responded to feedback on the garbage collector and significantly improved ASP.NET app startup.

ASP.NET App Suspension This feature is one of the top highlights of the .NET Framework 4.5.1 due to the significant 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 companies 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. This new “suspended” state releases critical resources used by the site for other sites to use, specifically CPU and memory, while still enabling the site to be resumed quickly.

The figure below shows the state transitions of ASP.NET sites using App Suspension. A Web site starts in the inactive state. It’s loaded into memory and transitions to active with the first page request. After a period of idle time, the site will be suspended, per application pool configuration (http://blogs.msdn.com/b/webdev/archive/2013/10/09/enable-and-monitor-asp-net-app-suspend-on-windows-server-2012-r2.aspx). Upon subsequent requests to the site, it can quickly return to the active state. This cycle can happen many times. Up until now, sites would get terminated and become inactive after a certain amount of idle time.

No code change is required to use this new feature. ASP.NET App Suspend is enabled automatically by configuring an IIS application pool for “Suspend” on Windows Server 2012 R2.

Microsoft conducted extensive performance experiments to measure the startup time gain for “resume from suspend” compared to “start after terminate.” Microsoft did these experiments on a machine under significant 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 after suspension. Microsoft also measured the improvement to site density. Microsoft were able to host about seven times more ASP.NET sites on Windows Server 2012 R2 when ASP.NET App Suspension was enabled. the next figure 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 http://blogs.msdn.com/b/dotnet/archive/2013/10/09/asp-net-app-suspend-responsive-shared-net-web-hosting.aspx.

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. The additional support also benefits 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 http://blogs.msdn.com/b/dotnet/archive/2012/10/18/an-easy-solution-for-improving-app-launch-performance.aspx.

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 information, as LOH might not be familiar to you. The garbage collector stores objects larger than 85,000 bytes in the LOH. The 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 analysis and testing.

Enjoy programming in the new VS2013 with the Update 1 and .NET Framework 4.5.1! More can be found  here(.NET Team Blog)

Adaugă comentariu

biuquote
Loading