Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
A question of speed with Response Compression Middleware #179
I just performed a little benchmarking here for Response Compression middleware vs. IIS's compression module. I hope I screwed up the test or my testing on my dev box explains this, because I'm not feel'in these figures.
Self-contained .NET Core Kestrel/MVC/Razor app (1.1)
Exact copy of App 1 with Response Compression middleware
I confirmed both working by hitting their endpoints with Fiddler and an
Using JMeter on my dev machine where the apps were hosted in IIS local. I took (32 threads, 500 loops) ~20K samples on each and found ...
... a large-ish ~33% diff.
I'm look'in down the road to the wonderful concept of ditching IIS totally when Kestrel can run as a public-facing server. If Kestrel doesn't offer compression, then the middleware will be the way to go. However, it seems slow. Can you comment on these figures? Do you think that's expected, or do you think my test is whacked?
Honestly we haven't compared the two. For this version we were more concerned about providing the basic functionality for non-IIS scenarios (e.g. direct WebListener and Kestrel). We did do a basic profile and identified a few issues with the GZipStream that the CLR team has started to address (dotnet/corefx#12549).
I slimmed down the test app. For example, I dropped logging and static file middleware. The results are more consistent between App 2 on IIS and App 2 on Kestrel than I imagined. I thought IIS would add some noticeable latency. Anyway ...
Overall, it looks like middleware is a bit slower. The difference here is ~28%, similar to my OP.
We periodically close 'discussion' issues that have not been updated in a long period of time.
We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.