Announcing the beta release of Web Pages 3.2.1

Announcing the beta release of Web Pages 3.2.1

Rate This
  • Comments 9

The NuGet packages for ASP.NET Web Pages 3.2.1 beta are now live on the NuGet gallery!

Download this release

You can install or update the NuGet package for ASP.NET Web Pages 3.2.1 beta using the NuGet Package Manager Console, with the following commands:

  • Install-Package Microsoft.AspNet.WebPages -Version 3.2.1-Beta –Pre

Prerequisites for this release

What’s in this release?

This release provides a performance improvement in rendering razor pages.

We worked with the MSN team on rendering large pages. When pages render over 80 Kilobytes of data, we end up with objects on the large object heap. When multiple layers of layouts are used this effect can be multiplied.

The result on the server is extra CPU usage, longer retention of memory, and even long pauses during Gen2 cleanup in the garbage collector.

Below is a table demonstrating the results of analyzing a perfview for a run. The CPU is held constant at about 68%, while large pages are being rendered. The table shows that the number of Generation 2 collections has been almost completely eliminated, and the result is higher request rate and a considerable reduction in pauses due to garbage collection.

Area Before (3.2) After (3.2.1) Delta %
Total request (count) 26,986 32,591 20.80%
Trace duration (seconds) 196.20 198.60 1.20%
Request/second 137.53 164.10 19.30%
CPU Load 68.80% 68.50%   -0.40%
GC CPU Samples 124,323 17,543 -85.90%
Total allocations (count) 55,357,146 57,222,949 3.40%
Total GC Pause (samples) 15,091 8,515 -43.60%
Gen0 GC (count) 403 1,216 201.70%
Gen1 GC (count) 290 367 26.60%
Gen2 GC (count) 229 2 -99.10%
CPU / request (samples/req) 19.73 16.47 -16.50%

 

Update:

How was this done? The Razor page took the data built up in a StringBuilder, and called .ToString() in order to write the string to the wire. Similarly this happened when rendering a Razor page inside a Layout page.

It’s common knowledge that you don’t want to build up a string by concatenating multiple strings. But when the result is large enough, you also don’t want to materialize it into a large string because of the reasons above.

Instead we copy the data into a small buffer, and write to the wire (or the layout page) from this buffer, thus avoiding allocating a large object. Further more the total memory consumed is now reduced because we never have to allocate the full string.

Questions and feedback

You can submit questions related to this release on the ASP.NET forums (MVC, Web API, Web Pages).Please submit any issues you encounter and feature suggestions for future releases on our CodePlex site.

Thanks and enjoy!

Leave a Comment
  • Please add 4 and 1 and type the answer here:
  • Post
  • It would be cool if you gave some idea of how you have achieved these improvements. Or perhaps point to a pull request that implements it on codeplex

  • You seem to have some problem with the Request/Second numbers.

    They are the same as the Total Allocations (count) numbers and don't match the Delta % column.

  • I know that Razor is the preferred view engine, but many (depending on when the app was first put on the drawing board) have inertia that keeps them using the old engine. Any idea how this helps .ASPX or how it compares with using .ASPX ?

  • @Nadav - Thanks for you comment, I have updated the table.

    @Mark - I added a short section on the change, here is the link to the commit - aspnetwebstack.codeplex.com/.../3fe0d348f00864e4f1eeaefbd027ea965787b892

    @Mike - This fix does not affect the .aspx view engine, the issue was in the page base class used by Razor.

  • perfect! thanks

  • That's some really awesome levels of improvements in the Gen2 and GC tests.

  • @Mike Johnson that inertia can be very difficult to overcome. Ultimately the value gained from converting a ASPX view to Razor is absolutely minimal. If you have a small page that is littered with all the <% %> and other crazy tags. convert it yourself and show people how much simpler it is.  After showing how much simpler it is and getting buy in from team members, the next NEW page you are going to build seek to do that in razor.

    This allows you to start to kill the ASPX view engine usage by attrition. New development will happen in razor, maintenance on existing ASPX views. Eventually the views will get replaced with new razor views. The best timing of this is when doing a large scale UI or UX enhancement. If you're replacing the backplane of browser to server, say perhaps moving to AngularJS, Meteor or similar, this is a great time to just do all the new work razor.

    One of the best ways to win over management support is stress you're not switching to razor to MAKE WORK. You're switching to razor to be MORE PRODUCTIVE. By outlining how you get to continue using all the existing work that there is no "loss" from going back and rewriting ASPX views for the sake of conversion to razor, you'll find most decision makers are open to change when it doesn't reduce EXISTING VALUE.

  • good

  • @Chris Marisic - great comments!

Page 1 of 1 (9 items)