
ASP.NET Core – 2300% More Requests Served per Second - benaadams
http://www.ageofascent.com/asp-net-core-exeeds-1-15-million-requests-12-6-gbps/
======
swalsh
I did .net development for 8 years, then moved to Ruby, but recently I started
working on a little side business built with .net core targeting deployment on
linux. I do most of my developing in Visual Studio Code on Mac osx.

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.

~~~
mrspeaker
Plus, or "only because"? For us it's "only because"... I have no intrinsic
loyalty to any provider and am happy to use any - I wonder if there's a
difference!

~~~
swalsh
If you mean, AWS vs Azure... it's an "only because". Although if they were the
same price, i'd still choose Azure.

------
bigdubs
I remember reading these results a little while ago and thought the numbers
were great until I saw the netty results. There is a lot of work left to be
done.

~~~
est
http.sys smokes netty in almost every way.

~~~
pbz
Doesn't looks like it does:
[https://github.com/aspnet/benchmarks/blob/dev/README.md](https://github.com/aspnet/benchmarks/blob/dev/README.md)
\-- look under experimental baselines

------
livando
It makes me happy to see .net developers get nice things.

------
Zekio
It is a great time to be a .Net Developer :)

~~~
snuxoll
Unless you want to use F#, then it's an awful time because it still doesn't
support .Net Core :(

~~~
abrodersen
I was able to get my F# code to compile using .NET Core yesterday! It's
difficult to find the correct project.json parameters and you have to build
the latest CLI yourself, but it works.

~~~
louthy
I used fsharp-dnx. The problem was it then doesn't support non .NET core
targets. So for library development it's a real pain in the arse when you want
to build multiple .NET targets (net45,net46,dnx...) with the same
project.json.

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.

~~~
pbz
It's still in development. In the past you weren't even able to glance inside
the sausage factory. If you want something solid then wait until 1.0 is out,
preferably 2.0.

~~~
louthy
Thanks for the history lesson. I am fully aware of what stage it's at. I am
commenting on the solution and what appears to be a meandering target, with
huge holes. It's currently at RC but no support for F#, no support for
SignalR, VS2015 tooling is comically bad, cripplingly slow build times, and
now a totally new toolchain (dotnet-CLI) that doesn't support the same
dependency system that dnx supports.

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.

~~~
pbz
They may call it RC, but it's barely beta. Recently they said they'd take
their time to get it right - less conference driven development. This is a new
start, SignalR will come after RTM, so lots of things won't be there. Think of
it as version 1 rather than 5. There's currently no VB support either, so F#
may take a bit.

------
sjark
Great job Ben, the dotnet core team and the asp.net team!

------
bsaul
anyone here could give the ideal dev environment for developping on mac and
deploying on linux while programming with asp.net core ?

~~~
jongalloway2
Easiest way to get set up is to run the installers at
[http://get.asp.net](http://get.asp.net) \- there are installers for Windows /
OS X / Linux there.

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](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...](https://docs.asp.net/en/latest/tutorials/your-first-mac-aspnet.html)

~~~
bsaul
Seems like deplying on linux server is still a second class citizen, am i
right ? Different, slimmed down framewoek, not so many resources for using
clouds other than azure (didn't find any article for deploying on heroku using
official tools for example).

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..

~~~
jcrts
Part of the point of the new asp.net core is that it's slimmed down
everywhere, not just linux (you're not getting jipped, they're just cutting
off weight you don't need).

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).

------
MrBuddyCasino
It's on! Waiting patiently for the Techempower entry...

------
aninteger
It's unfortunate that they don't have the numbers for Linux and instead used
the Windows operating system. I'd like to see the Linux benchmark be on par
with Windows (or ideally better) but I'm not sure if there is an interest from
Microsoft to meet or exceed performance of Windows with a Linux based host.

~~~
jongalloway2
Update: Checked with the team, latest Linux benchmark for plaintext with
pipelining from January was 928,023 rps, which is a lot closer to the Windows
numbers (78%). Updated here: [https://github.com/aspnet/benchmarks/#plain-
text-with-http-p...](https://github.com/aspnet/benchmarks/#plain-text-with-
http-pipelining)

Linux benchmarks are included here:
[https://github.com/aspnet/benchmarks/](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](http://live.asp.net)),
here's one going over the rig and perf in general:
[https://www.youtube.com/watch?v=7O81CAjmOXk&list=PL0M0zPgJ3H...](https://www.youtube.com/watch?v=7O81CAjmOXk&list=PL0M0zPgJ3HSftTAAHttA3JQU4vOjXFquF&index=21)

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+...](https://github.com/aspnet/KestrelHttpServer/pulls?q=is%3Apr+is%3Aclosed))
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).

~~~
mistermann
Who in your opinion is the most responsible for the remarkably positive change
in certain parts of Microsoft? (ASP.Net and Azure would be two examples of the
new and improved Microsoft, Office would be an example of the old Microsoft
mentality.)

~~~
bdcravens
Much of the openness seems to coincide with when Satya Nadella became CEO.

~~~
mistermann
Do you think he has any interest in enhancing the programmability of Excel,
for the first time in over a decade? (Serious question)

~~~
bdcravens
Desktop, no. Hosted version, maybe.

------
thepumpkin1979
what's special in ASP.NET core that allows then to achieve this?

~~~
hhandoko
As I understand it, because it comes with less bloat than its predecessors
(i.e. more focused library). From the blog post itself:

    
    
      "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."

~~~
thepumpkin1979
Really, that's it? I thought it'd involve something about concurrency,
networking or some IOCP magic going on.

~~~
pbz
The fastest code is the one that doesn't run. Joking aside, there have been
numerous low level improvements with Ben making big contributions - thanks
Ben!

------
dschiptsov
Was it this bad before?

------
CyberDildonics
I still don't get why anyone would brag about how poorly they optimized
something the first time around.

~~~
jongalloway2
ASP.NET wasn't necessarily slow previously - for example, StackOverflow is
running on it, and they're getting some pretty good perf (albeit with pretty
beefy machines): [http://nickcraver.com/blog/2016/02/17/stack-overflow-the-
arc...](http://nickcraver.com/blog/2016/02/17/stack-overflow-the-
architecture-2016-edition/)

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).

~~~
kristianp
Speaking of performance. I read that blog entry, and saw that they use their
own DB library called Dapper:

[https://github.com/StackExchange/dapper-dot-
net](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.

~~~
jongalloway2
They're different kinds of tools - maybe like comparing an RV to a motorcycle,
or a guided missile to a sniper rifle. Or a...

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...](https://github.com/StackExchange/dapper-dot-
net/issues/246#issuecomment-90598911)

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.

~~~
yread
Great explanation. If you want to get even closer to the metal there is
Simple.Data
[http://simplefx.org/simpledata/docs/](http://simplefx.org/simpledata/docs/)
where you write queries like

    
    
        var albums = Database.Open().Albums.FindAll(db.Albums.GenreId == 1); 
        //or FindAllByGenreId(1)
        foreach (var album in albums)
        {
    	  Console.WriteLine(album.Title);
        }
    

and they return dynamic objects. It's smart about cases, _s and all with 0
configuration.

