Scenario: we performed load tests using VS 2015.
One cool thing with ASP.NET of old times, was that it registered perf counters on the server, which were included by default in load tests.
So you easily got key indicators such as request queue length, avg request wait time, avg request execution time, application restarts, etc.
This was mega-useful to diagnose all kinds of problems and have a better understanding of what happened on your server.
Of course, now that System.Web
is not even loaded, those counters are worthless. IIS does not seem to offer much help either.
Is there any way to get a similar set of perf counters back for ASP.NET Core? Any script to register or something?
It is very valuable to be able to monitor the server health state.
At this time there are no perf counters in ASP.NET, in part because .NET Core doesn't support them at all. We could possibly make them work when running on .NET Framework, but even that is not planned at this time.
Noted, thanks for the answer.
That's kind of a serious step back in terms of monitoring capabilities :disappointed:
step back in terms of monitoring capabilities
If you compare to ASP.NET 4.6? Yes.
If you go .NET Core, it should be considered a new product IMHO. So no real step back.
The only steps it need to take is forward. :wink:
@MaximRouiller I don't quite agree with you.
Why would I not compare with ASP.NET 4.6? It shares the name, it's a rewrite of "quasi-same" public APIs, it's probably the future of serving web pages on .NET and it even started its life with a "5" moniker.
When starting my current project I had a choice between ASP.NET 4.6 and ASP.NET Core. So it's natural comparing them. Even though I run on the full framework (only because too much stuff is missing on Core at the moment), I choose Core because it's many steps forward in several areas compared to 4.6. Yet as is expected from a total rewrite, it's a step back in others (perf counters isn't the only thing I'm missing right now).
I am sure the ASP.NET team will fill in the gaps, it's a 1.0 after all. I have no problem with that but there's no denying that _right now_ you win some, loose some if you choose ASP.NET Core over ASP.NET 4.x.
total rewrite
You get it right there. You can compare any frameworks for features but in the end, it's like you are comparing ASP Classic to ASP.NET (hey! they even share the same name!).
While it may be sold as an "upgrade" it is not. It's a complete rewrite just like ASP.NET 1 was when ASP Classic was the standard.
The difference here is that we are bringing cross platform compatibility into the mix. So what you do in ASP.NET Core will need to be compatible in Linux and OSX. You can't ship a cross-platform framework with bits not compatibles to certain OS.
And yes, the gap will eventually be filled but I don't think the way I see the framework isn't too far from the facts. :smile:
@Eilon feel free to close this question, or keep the issue open as a remainder for monitoring features.
I understand you don't have resources for 1.0, but I strongly think you should think about it for future releases. It could be perf counters when running on Windows, and the equivalent native concept on Linux/Mac.
Motivations:
Because we run on 4.6 we still have the non-ASP counters available, but it is my understanding that they are also gone from .NET Core? I guess my request should be extended to those counters as well. Because finding out how much time you spend in JIT or GC, how many forced full GC collections, lock contention, thrown exceptions/sec, memory allocations, etc. etc. is mega useful when you are doing perf work, especially on projects you don't own.
@MaximRouiller
It's not important but we really don't agree.
ASP.NET is the perfect example because it was a _forced replacement_ of ASP Classic. When it came out the message was: ASP Classic is dead, new projects should be ASP.NET and old projects should migrate. So even though it was a full rewrite, it's 100% pertinent to compare what ASP.NET did better and what it did worse than ASP Classic.
Other example: Roslyn. As of VS 2015, Roslyn is a full C# compiler rewrites that _replaces_ the old native one. Now isn't it fair to compare them? Of course it is. If Roslyn was the VS 2015 C# compiler and it did _not_ support async
, you sure would have said it's a step back.
ASP.NET Core is not as clear-cut because MS does not market it as a _replacement_ of ASP.NET 4.6... yet. Because I don't believe for a sec. that MS is going to continue to evolve and maintain ASP.NET MVC 4.6 for many years. When ASP.NET Core is mature enough, MS will say that MVC and Web API projects should migrate to it and it will become the "new" ASP.NET stack on both Core _and_ Framework.
@jods4
We'll have to agree to disagree. :smile:
Roslyn was meant to replace feature-for-feature the old compiler + more features. It relies on C# Specifications which are available for download and no features from C# was dropped. I'm pretty sure however that the IL generated by Roslyn and the IL generated by the old compiler aren't the same.
It is not fair to compare them because ASP.NET doesn't have a (public) specification. It doesn't say which feature must be implemented, how and how it should behave in certain edge cases.
Microsoft may have that internally but it's not available for download and it is not a standard.
It _might_ be intended to replace ASP.NET 4.6 in the future. But we have no idea what is coming up the pipeline.
As far as we are concerned, we might not even have Performance Counter on Windows in 2 years. ASP.NET Core dropped WebForms, dropped IIS as the only possible host, runs in a separate process from IIS, no more Global.asax to configure your application, complete overhaul on how appSettings
are loaded, complete overhaul on how the whole framework is managed on a single machine, etc...
For me, it's only comparable to the last release as there's common functions, concepts and it's in .NET. Everything else has been rewritten and a migration would be just as hard as it was from ASP Classic to ASP.NET.
/rant /explanation
Fun arguing with you btw. :+1:
@jods4 we would certainly like to have some perf-counter-equivalent available to use in ASP.NET Core and EF Core, but at this time it hasn't become a high enough priority.
Indeed a problem with perf counters is that they are Windows-specific, and we would ideally have a cross-platform solution (even if it's a different solution on each platform). I thought .NET Core at one point was going to have something like this, but I just can't recall right now.
@Eilon Have you guys discussed the profiler scenarios? You know... companies that will want to profile the core framework and extension points to help them out.
@MaximRouiller is there a particular type of profiling you're thinking about? There are already profilers that work on the new system, e.g. JetBrains dotMemory (which we use a lot within our team).
@Eilon Not anything in particular since I'm pretty sure the Glimpse guys will give you feedback :wink:
I was more curious if it was a concern that was taken into account while building the framework.
If the JetBrain tools and Glimpse works... I'm covered for at least 95% of all my scenarios (_warning: 68% of statistics are just made up numbers_).
Hi,
Not sure if this is the right place to discuss this but with the lack of perf counters like response time, request queue length etc, what are the alternatives to measuring equivalent metrics for asp,net core?
We don't have anything as yet but are looking at using EventCounters as an alternative. You can see that work in progress here https://github.com/aspnet/Hosting/pull/886.
FYI: IIS and WebListener have a few built in perf counters that apply.
https://msdn.microsoft.com/en-us/library/windows/desktop/cc307239(v=vs.85).aspx
After an year, is this still an issue or we have perf counters alternatives/replacements for asp.net core?
Also some further discussions here: https://github.com/aspnet/Logging/issues/708
Closing this issue because this topic is covered in some other areas.
Most helpful comment
We don't have anything as yet but are looking at using EventCounters as an alternative. You can see that work in progress here https://github.com/aspnet/Hosting/pull/886.