ASP.NET 5 focus on dnx451 / dnx46 performance

Question

With ASP.NET 5, everything has to be tuned to the choice, the application only downloads selected libraries, which is surprising. Old ASP.NET features were encapsulated in the System.Web namespace, which had everything you might need to create an ASP.NET application. There was real cost to populate all of these unused libraries in memory, so ASP.NET 5's approach is to choose what you need, rather than linking to large libraries of unused code.

My questions:

• Is this approach and performance improvement option available only for ASP.NET 5 that focuses on .NET CORE? or is ASP.NET 5 aimed at a complete Windows infrastructure getting all these nice features?

• When targeting dnx451 or dnx46, are they still dependent on System.web and are all unused libraries still loaded into memory, such as older versions of ASP.NET?

• ASP.NET 5 supposedly takes up about 2 KB of memory per request, whereas an older version of ASP.NET takes up to 30 KB per request. Is this excellent performance improvement possible only when targeting dnxcore50? or does this also apply to dnx451 / dnx46?

• When running ASP.NET 5 dnx46 on IIS 7.5+, is System.web still not loaded? (Not sure, but I think IIS and System.web are integrated, correct me if I am wrong).

• Finally, what is the difference between an ASP.NET 4.6 application and an application running on ASP.NET 5 (dnx46)? What improvements do the latter have over others?

Anyone PLEASE clarify this for me? I cannot find a clear answer to these questions.

Answer 1

Is this a choice of approach and performance improvement that is only available for ASP.NET 5 that focuses on .NET CORE? or does ASP.NET 5, aimed at a complete framework in Windows, get all these nice features?

No, a significant portion of the enhancements offered by ASP.NET 5 also applies to DNX451 (as well as the full version). This is especially true for Kestrel (the new "universal" web server for ASP.NET 5), where massive RPS improvements affect both versions.

When targeting dnx451 or dnx46, are they still dependent on System.web and are all unused libraries still loaded into memory, such as older versions of ASP.NET?

No. With a new level of hosting, System.Web never loads even when using IIS.

ASP.NET 5 supposedly takes up about 2 KB of memory per request, whereas an older version of ASP.NET takes up to 30 KB per request. Is this excellent performance improvement possible only when targeting dnxcore50? or does this also apply to dnx451 / dnx46?

Thanks to the extensive work done by the Kestrel community, the distributions (and therefore the "bytes per request") have decreased significantly since the first beta, and this affects both versions. Using CoreCLR is more likely to help reduce the amount of memory needed to host the entire application (since you are referencing lighter assemblies), but the effect on "request bytes" should be barely noticeable.

Of course, the impact of CoreCLR will mainly depend on how many links you have in your project: in most cases, the memory gain should be marginal (you have easier assemblies, but due to the completely modular nature of CoreCLR they are much more numerous).

When running ASP.NET 5 dnx46 in IIS 7.5+, is System.web still not loading? (Not sure, but I think IIS and System.web are integrated, correct me if I am wrong).

No, thanks to a new level of hosting (the previous IIS integration, Helios, is used to download System.Web , but this no longer applies to the HttpPlatformHandler). Note that IIS no longer "hosts" your application: now it just acts as a reverse proxy. Everything is actually handled by a separate DNX workflow, initiated and controlled by IIS.

Finally, what is the difference between an ASP.NET 4.6 application and an application running on ASP.NET 5 (dnx46)? What improvements do the latter support?

Hosting an “ASP.NET 4.6 application” on the new stack will be difficult (if not impossible), especially if it relies on System.Web and does not use an abstraction layer such as OWIN (ASP.NET 5 provides a level of compatibility with OWIN).