Kestrelhttpserver: Switch default transport to sockets
Currently, it is our goal by 2.1.0 to make sockets the default transport. We made the switch in early builds of 2.1.0 but reverted that for preview1 (https://github.com/aspnet/KestrelHttpServer/issues/2220) due to performance issues.
Motivations:
- broad platform support. Wherever managed sockets are supported, Kestrel should work. Doesn't require recompiling libuv to bring up a new OS.
- source-build. (https://github.com/dotnet/source-build). In current form, Kestrel packages can't be produced in a source-build environment
- ecosystem. Helps to drive improvement to the .NET sockets implementation, which benefits anyone else using managed sockets.
/cc @halter73 @davidfowl @muratg
natemcmaster
All 9 comments
@halter73 shouldn't the announcement prefer Microsoft.AspNetCore.App over Microsoft.AspNetCore.All? EDIT: Oh looks like i can't read properly, so App won't contain Libuv but All does.
Suchiman
on 14 Mar 2018
@Suchiman Your edit is correct. That's the main thing that makes the change breaking.
halter73
on 14 Mar 2018
Do the managed sockets have similar performance compared to libuv?
ondravondra
on 15 Mar 2018
@ondravondra yes that was the prerequisite for the switch and why preview1 still ships with libuv. I think it might even be.a little faster already
NinoFloris
on 15 Mar 2018
@halter73 this is done, can you close this issue?
davidfowl
on 16 Mar 2018
Just a heads up, the announcement has the tag 2.0.0-preview2, not 2.1.0-preview2
nickalbrecht
on 16 Mar 2018
@nickalbrecht thanks for spotting that. I updated the milestone on the announcement.
natemcmaster
on 16 Mar 2018
Do the managed sockets have similar performance compared to libuv?
@ondravondra yes that was the prerequisite for the switch and why preview1 still ships with libuv. I think it might even be.a little faster already
Couple of months ago, it was indicated that performance regressed when switching to sockets https://github.com/aspnet/KestrelHttpServer/issues/2220. Are there any before/after performance measurements to bring about concreteness to the mix?
ghost
on 3 Apr 2018
@kasper3
There is http://aka.ms/aspnet/benchmarks
If you navigate to page 1 with the pager at the bottom, there's a graph that shows Socket I/O by over a million RPS ahead of Libuv.
If you go to page 2 it looks differently so i don't really understand how to read them.
EDIT: Ah i think i see my mistake. Sockets PlainText Platform is a bit faster than LibUv PlainText Platform and both are ~1.5 million RPS faster than Kestrel LibUv PlainText which is a bit faster than Sockets PlainText. Interesting that only the Platform Level Benchmark of Sockets beats LibUv.
Suchiman
on 3 Apr 2018
Related issues
chtbof
路
3Comments
codepunkt
路
7Comments
ciriarte
路
7Comments
felschr
路
6Comments
txdv
路
7Comments
Most helpful comment
@kasper3
There is http://aka.ms/aspnet/benchmarks
If you navigate to page 1 with the pager at the bottom, there's a graph that shows Socket I/O by over a million RPS ahead of Libuv.
If you go to page 2 it looks differently so i don't really understand how to read them.
EDIT: Ah i think i see my mistake. Sockets PlainText Platform is a bit faster than LibUv PlainText Platform and both are ~1.5 million RPS faster than Kestrel LibUv PlainText which is a bit faster than Sockets PlainText. Interesting that only the Platform Level Benchmark of Sockets beats LibUv.