As always I'm interested in how ServiceStack holds up performance wise against alternatives out there. The reason I started using SS years ago was due to the performance wins over WCF and Web API at the time. Also the perf advantage in ServiceStack.Text over JSON.Net.
So I came across this and this article and wanted to know how ServiceStack holds up? What are your thoughts?
ServiceStack is a web framework that runs on top of a HTTP Host. It currently runs on ASP.NET and HttpListener self hosts. These benchmarks are measuring raw performance of .NET Core's Kestrel HTTP Host. Performance of HTTP on Mono has always been poor and the only way .NET is going to run well on Linux (where Tech Empower benchmarks are run) is to run on .NET Core (i.e not run on Mono) which is our priority to support in the future starting from last v4.0.62 release where we've released .NET Core builds for ServiceStack.Client and ServiceStack.Text, you can vote on this feature request to get notified of updates as we release support for .NET Core.
A new framework called "fastify" recently came out claiming some new performance improvements over other nodejs web frameworks and published a performance benchmarks repo. I added asp.net core 2.0, webapi and servicestack.core to the repo to do some benchmarks against asp.net core.
My results are posted here (ran using a MacBook Pro).
The servicestack raw handler perfoms pretty close to webapi, but the [Route] attribute and the [FallbackRoute] strategies don't measure up as well. The pure asp.net core ".map" and raw handler performance are impressive. WebApi is 1/2 as fast as that. ServiceStack varies depending on the strategy but generally slower. Open to feedback on how to re-structure the tests ... If you try to run these for yourself by cloning the repo, you'll have to go into the Startup class and comment/uncomment certain sections before running autocannon.
Thanks Matt, we'll investigate it, can you publish numbers for sync Services, to see if it's related to async overhead?
Updated the tests and included sync numbers, see here
Very interesting. Looks like some time needs to be spent getting ServiceStack speed back up.
We're getting different numbers to the results posted, but perf profiling/optimizations are high on our TODO list, ideally we'd like to focus on it before the next v5 release.
FYI now that v5 refactoring has been completed I've been able to start looking into this and just found and resolved a major perf issue by delaying disk access until it's needed which had a significant effect on RPS so the latest v5 should have much improved performance.
That sounds interesting Demis! Please do let us know about any more perf wins
@dylan Yeah any I/O is a major perf killer for raw request benchmarks which was getting 21-22k rps before this change and is now getting ~40k rps for
/hello JSON HTTP API on my iMac, just slightly more than an equivalent JSON API in Web Api at ~39k.
FYI I'm maintaining raw benchmarks for different basic request types at: https://github.com/mythz/SSvsWebApi/tree/master/src
Hi Demis. Any more perf-oriented changes planned/upcoming?
We added some perf optimizations in the last release, but there's none planned in the immediate future.
I'd like to move to
Span<T> to replace where we're currently using
StringSegment but need to make sure it has minimal disruption with existing .NET v4.5 projects. This will require an external dependency to System.Memory in all packages, which I'd prefer to not have any external dependencies but it's something we'll look at adding after it moves out of preview release.