ASP.NET Core – 2300% More Requests Served per Second
ageofascent.com
ageofascent.com
Not going to lie, i've had my pain. Dependencies are still hell, getting stripe to work meant taking an open source library, and modifying it... and there's still some stuff I want to use, but haven't gotten working yet.
That said the platform keeps getting better, and I love what i'm seeing. I feel like it combines a lot of what I loved, with a lot of what I learned to love in Ruby.
Plus Microsoft is offering so many sweet deals with Azure, its hard to pass it up.
My understanding is that the ASP.NET team started at the bottom of the stack and is working their way up. They want to get fundamental HTTP serving basics nailed first. I think that makes sense - they were getting around 170k rps in September, so there were definitely some things to sort out at the basic HTTP serving layer.
(Or does that even make sense, given that undiscovered exploits might require a hardware upgrade?)
The whole thing is a total mess at the moment, so I'm personally going to stay away from dnx until MS produce something that's close to their old RTM quality releases. It seems there's even a rival system with the dotnet CLI.
So I disagree strongly with the OP, it's not a great time to be a .NET developer. The improvements to C# and F#, yes, fantastic. But the ecosystem around it is so brittle at the moment; which is something that we never had to deal with in the past, and was one of the big selling points of the MS ecosystem.
That doesn't sound like a RC to me. I have a general feeling that the RTM standards are slipping massively at MS. Windows 10 was a dog when I tried it - and obviously not finished, VS2015 is very unstable, then the issues above... It feels like stuff is being pushed out the door much earlier than it previously would have been.
I do appreciate the direction they're taking, it just feels rudderless atm.
I just switched from a 3 years full-time F# position to a full time PHP dev and let me tell you I'm starting to understand how much of a good time I was getting.
https://github.com/Microsoft/visualfsharp/wiki/F%23-for-Core...
http://lastexitcode.com/blog/2016/01/01/DNXSupportInXamarinS...
It's free too (use the download link at the end of the page):
If you'd rather install via command-line, there are walkthroughs for all platforms here: https://docs.asp.net/en/latest/getting-started/index.html
There's an easy tutorial showing how to dev on OS X using Yeoman and VS Code (free) here: https://docs.asp.net/en/latest/tutorials/your-first-mac-aspn...
That's not really surprising, because ms still got to make some money somehow, but that means i'll have to wait a bit longer to get anything descent on the server side..
And to be fair, other cloud providers are responsible for implementing their own C# IaaS stack. To use heroku as an example, they implement their own stack and add languages that they support at their own pace (I think they only allowed JS/Python/PHP/Ruby the last time I used them).
I continue to use Mono and Xamarin Studio, although I'm stuck on an old version of Xamarin for now because I'm using Mavericks. At some point, I'd like to try OmniSharp with Emacs.
Last month, I did some Linux profiling in our perf lab. As part of that, I ran the exact same benchmark shown in that graph on the exact same equipment and got over double the RPS numbers we got back in November much like we did on Windows.
I just updated the https://github.com/aspnet/benchmarks/ repo with the linux numbers I got last month since Ben's blog post has brought some increased attention to it. We plan to do a more complete benchmark run soon so we can update more numbers.
Linux benchmarks are included here: https://github.com/aspnet/benchmarks/
The team definitely wants to make ASP.NET Core run fast on Linux, too. The ASP.NET team perf rig runs both Ubuntu 14.04 LTS and Windows Server 2012 R2. A lot of the perf enhancements are due to community pull requests, mostly from Ben (author of parent post). The perf work's been discussed a lot on the weekly community standup calls (http://live.asp.net), here's one going over the rig and perf in general: https://www.youtube.com/watch?v=7O81CAjmOXk&list=PL0M0zPgJ3H...
There's a lot going on right now - both ASP.NET Core and .NET Core are new to Linux, the teams are working on getting 1.0 releases out the door, etc. I expect perf on both Windows and Linux to continue to improve, both before and after 1.0 release. This week on the community standup, Damian said that perf is one area that's lower risk as RTM approaches, and that they're hoping for more improvement there.
And this is very much an open source project, as you can see from the merged pull requests in general (https://github.com/aspnet/KestrelHttpServer/pulls?q=is%3Apr+...) and the fact that Ben (non m-dollar) is battling with a Microsoft dev to be the top contributor. It'd be great to get some more devs with Linux HTTP serving background contributing.
I think I remember that they only posted benchmark updates when there was a significant change. Checking with the team now.
Source: long time ASP.NET groupie, Microsoft employee (until they find out I'm goofing off on HN instead of replying to e-mail).
"ASP.NET Core and .NET Core come with the great advantage of only including the libraries and functions you explicitly want to use in your application rather than bringing in the entire framework. So you only “pay”, programmatically speaking, for what you use."There must really be something I didn't understand here.
You can just be assured that ASP.NET is not going to suplex you with poor performance.
Most sites, even relatively high traffic sites, don't serve 50k requests per second.
However, it wasn't granular or modular. For a lot of sites, it was a good balance of features to performance, but in a lot of cases you paid a performance penalty for features you weren't using. That includes the memory footprint penalty - each ASP.NET site loaded up a chunky system.web DLL with the kitchen sink. Back in the day that was fine, but as there are a lot of front-end heavy sites now that use servers mostly as API endpoints, and package managers are pretty standard, devs like to only pay the performance cost (including memory footprint) for the features, middleware, etc., that they're using. That was a big design consideration for ASP.NET Core, and you can really see the results in these specific benchmarks (Techempower plaintext).
https://github.com/StackExchange/dapper-dot-net
I was suprised to see that it's almost 4x faster than linq2sql and more than 10x faster than entity framework. (according to the table "Performance of SELECT mapping over 500 iterations - POCO serialization"). There must be a lot of slow sites out there running on entity.
Well, anyhow, while at a high level they're both tools that map between database commands and statically typed objects, the approach is very different.
Entity Framework is a full object relational mapper - it's generally the active record pattern, and it supplies things like migrations and entity tracking. The design philosophy is to abstract the database mechanics as much as possible, so you just work with collections of objects (e.g. DbSet<Person>) - add new Person instances to the set, set properties on them, etc. EF converts your intent into database commands (SQL queries in many cases, although EF7 supports some non-relational databases and in-memory storage, too). EF is tracking the state of all your objects, so it knows whether they need to be updated in the data store. That might be fine for a lot of cases - if you're managing a small list of products or customers, working on an intranet app, etc., you're not going to see a difference. I've seen (and fixed) a lot of horrible SQL queries that intranet devs built by concatenating strings; EF is at least going to usually give you decent, secure SQL. (If you're gnashing your teeth right now because EF crushed your dreams in the past, they've done some decent work on SQL generation lately, including some good stuff in EF7). It works pretty well on a lot of apps in lots of dev shops, and can be tuned to work well on big apps if you know what you're doing.
Dapper, and other "micro-ORMs" want to work closer to the metal. Dapper's tuned to taking the results of a database command (SQL query) and populate static objects. There's no entity tracking, state management, etc. Take results of a database query, stuff it into a bunch of object properties, walk away. Because of that, benchmarks showing the performance of select mapping over 500 iterations - POCO serialization are going to run a lot faster, just as (sorry, can't help myself) a motorcycle's going to beat an RV on a race down a tiny dirt trail.
So there may be some slow sites that are running on EF that would be faster on Dapper, but not without evaluating how they're interacting with the database, how they're doing database updates, etc.
Also, to be fair, you can disable a lot of features in EF (or other more fully featured ORMs) and get perf numbers pretty close to micro-ORM's like Dapper. See this comparison: https://github.com/StackExchange/dapper-dot-net/issues/246#i...
However, if you're turning off all the features and hand crafting SQL statements and working with untracked entities, you probably want a micro-ORM, anyways.
var albums = Database.Open().Albums.FindAll(db.Albums.GenreId == 1);
//or FindAllByGenreId(1)
foreach (var album in albums)
{
Console.WriteLine(album.Title);
}
It's exciting for ASP.NET, but part of this is also to say, "The .NET Core platform is not a joke. In fact it's a good deploy target."