Just wondering how is it with performance is asp.net core in comparison with ASP.NET 4.6. Did someone performance tests?
In generaly ASP.NET Core has much better performance than current ASP.NET 4.x versions. Architecture has changed and ASP.NET Core is no longer based on System.Web.dll (This in itself has a positive effect on performance). Great article about ASP.NET Core performance is on ageofascento.com.
I don't know between 4.6 and Core but here's the ASP.NET Benchmarks repository.
They load test the framework and see at which point it fails. I think what you are looking for is inside one of the Excel spreadsheet in the repository.
Related
Was Kestrel present in .NET Framework or was it developed specifically for the ASP.NET Core?
I was not able to find an answer to this question by just googling, so I decided to ask it here. I need it because I am intended to work with the ASP.NET Core and would like to know the history of development better, because knowing it allows to better understand the decisions made by developers.
In order to give an official answer to this question, I copy here comments from #AnkushJain and #andrew-morton:
Kestrel is not available for .NET Framework. It is born with the origin of ASP.NET Core.
[In addition] since Kestrel is not a fully-featured web server, you should run it behind IIS or NGINX. It was designed to make ASP.NET as fast as possible but is limited in its ability to manage security and serve static files.
For a .NET Core 2.0 project, I used Microsoft standard health check libraries which are clearly documented based on code for .NET Core 2.0. Since less than a month, suddenly, this is deprecated. The new readme file, refers to an alternative for .NET Core 2.2 .However, the version of .NET Core that is production ready, recommended and has long term support, is version 2.1 which is exactly what I use now for a new project.
So I am in trouble. What is the supported way of implementing health checks for .NET Core 2.1? This used to be clear for .NET Core 2.0 and shall be clear for .NET Core 2.2 but for .NET Core 2.1 it is unclear what I should do.
You answered your own question actually, with the reference links.
ASP.NET Core 2.2 comes with its own official heath check, see Docs and the ASP.NET Core 2.2.0-preview1 blog post for the new health service.
You can use either one (2.2 or your old solution) for the ASP.NET Core 2.x life-time. Since the old one is deprecated it won't be updated for newer versions of ASP.NET Core, but you should expect it to work for the 2.x lines.
By the time ASP.NET Core 3.0 is out and you want to migrate to it, you should switch to the health services introduced in ASP.NET Core 2.2.
General consensus about new features in minor versions (which replace or change previous behavior) is to support them for the current main version and drop the old functionality in the next major, i.e. the new [ApiController] attribute and automatic model validation was added in ASP.NET Core 2.1. By default, the 2.0 compatibility will be used and the new behavior won't be available unless you opt-in. Once 3.0 is released, the old features/behavior will be removed and only the new one will be used.
Our app is based on ASP.NET Core 2.0. It works fine in development environment but we see an oauth error when published to production.
All the documentation on asp.net core seems to point to using ILoggingxxx interfaces. The examples I found typically call logging.AddConsole() method so that the log lines can be viewed in VIsual Studio debug window. I am wondering if the good old trace.axd is still available under asp.net core. If so, I would appreciate the steps to enable tracing. Regards.
trace.axd is exclusive to applications based on .NET Framework and ASP.NET 4.x. It is not available in ASP.NET Core applications at all.
I find that one of the key benefit of Asp.Net core is multi fold performance improvement (requests per second) compared to traditional Asp.Net. I find many bench mark sites talks about Asp.Net core performance, but I'm not sure if the performance is based on Asp.Net core with .Net core framework or the same performance benefit applies to asp.net core (full .Net framework).
Any idea/articles that explains/compares performance between asp.net core (.Net core) vs asp.net (full framework)?
Thanks
I recently develop using ASP.NET Core 2.0, and I have the same question regarding performance improvement beside its excellent cross platform support. There are many comparison from google search result, and the briefing idea is:
ASP.NET Core 2.0 is about 6x-23x faster than ASP.NET 4.6
Here are two resources for your reference
https://www.ageofascent.com/2016/02/18/asp-net-core-exeeds-1-15-million-requests-12-6-gbps/
https://github.com/aspnet/benchmarks
ASP.Net Core 2.0 is nearly 2x faster than ASP.net 4.6 and also from ASP.Net 4.7 framework.
When comparing full .Net framework vs .Net Core's performance, ASP.Net Core wins but .Net Framework also has some advantage because of some pre-built feature works with asp.net framework.
But in terms of speed, ASP.Net Core(.Net Core) wins the game even from Node.js
We are checking the asp.net core 2.0 performance and found out this:
Asp.Net core application hosted/running under IIS using ASP.NET Core Module
performance is worst in about 60% then Full frame work.
Second case: same application self-hosted and using IIS as reverse proxy with URL rewrite module increase performance in about 20% better than Full FW.
FW 4.6.1.
Another aspect that have major impact on performance is logging. Insure that application under test doesn't write debug/info log to console (by default).
Log configuration under test should not log info and debug.
Second problem that we deal with is: Asp.net core performance issue when consuming WCF service. We found out that in current version 2.0.5 the performance vs Asp.Net FW worse in about 70% and what is more important have a huge error rate (23%) of all test.
The problem here is laying in port exhaustion. MS recommend to increase the number of ephemeral ports. Increasing then number of ephemeral port improved the error rate, but not solved the problem.
Our test setup:
Asp.Net core2.0 and Asp.Net FW apps with WEB Api controller that return some string
Load test: start with 5 user increase by 5 every 30 seconds. Test is running for 8 minutes
Read out the ASP.Net Core 2.1 RoadMap. I think MS aware for those issues and they will fix major issues in 2.1 release.
We are waiting for it.
With ASP.NET Core 1.0 release one can run on either .NET Core or the full .NET Framework per the documentation here. I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?
I understand the difference between the full .NET Framework and .NET Core. However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6? I thought the idea was a 1-2 punch with ASP.NET Core atop of .NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc. Without .NET Core I don't believe anything on that list is still valid, so what is the use case for the full .NET framework + ASP.NET Core? What does ASP.NET Core on it's own still provide to me without .NET Core?
.NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc.. Without .NET Core I don't believe anything on that list is still valid
The only benefit you don't have if you choose the full .NET framework over .NET Core is being cross platform. All the other benefits of deployment, modularization, docker, performance, etc... are still valid.
We actually run our ASP.NET Core web app on the full framework and now we enjoy the benefits of having Dependency Injection as a 1st class citizen, having NuGet built in, having an lean HTTP request pipeline which makes our performance better, open sourced (so all the issues can be solved by a short visit to GitHub), modularity (still have to come across something we couldn't customize to our own needs after almost a year now), and so on. And we know we don't need to deploy on any other OS than Windows, so we can still have all the benefits of the full framework.
Update from Tseng
Well, you can still target full .NET Framework under Linux for example. There you need mono 4.6 installed there. There are some limitations as not all classes are implemented in mono, but a majority is and around the corner case (i.e. encryption) you have to work around
Update from atconway
It's also worth noting at the time VB.NET is not supported by .NET Core if that's a requirement.
However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6?
If I use ASP.NET 4.6 instead of ASP.NET Core 1, then I won't be able to use ASP.NET Core MVC. None of the features on that documentation page would be made available to me! I would have to build an MVC5 application. Boooo!
I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?
I'm assuming that another way to ask this would be: "why would you take the red path when you can take the brown path?"
One argument for doing it this way is deployment. If you've got a bunch of existing Windows servers with IIS on them, you're going to need to install additional software on each of them and set them up to run Core applications. IIS just becomes a reverse proxy for your .NET Core app.
However, if these apps were built on the .Net Framework instead, you wouldn't have to do this. You could still use web deploy (for example) to move them onto the servers. Maybe you've got some other existing IIS configuration settings that you don't want to migrate.
Using ASP.NET Core 1.0 targeting the .Net Framework, you can get the benefit of the new features in ASP.NET Core MVC without having to change your existing infrastructure.
One important benefit of using Full .NET framework with Asp.Net core is availability of mature libraries and frameworks that are developed mainly to target previous version of .NET.
But by passing of time and implementing more and more libraries to target .NET core and developing more features for .NET core itself this benefit may fade out.
Having to leverage legacy technologies like OLE DB that will never be implemented in NET Core System.Data is another reason.
One thing to consider is that it can be a migration path. Say, for example, you have an existing ASP.NET 4.6 application that you intend to migrate to .NET Core. You want to take advantage of ASP.NET Core features like TagHelpers, Dependency Injection, etc., but you aren't ready or able to use .NET Core framework. So, you develop the ASP.NET Core application, targeting just the .NET full framework. Then, you take the next step and multi-target, going for both .NET full framework and .NET Core framework. This gives you the flexibility to easily deploy to IIS with the full framework or cross-platform with the core framework. From there, you can decide if you want to eliminate the full framework or not.