A question of speed with Response Compression Middleware #179
Description
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.
App 1
Self-contained .NET Core Kestrel/MVC/Razor app (1.1)
IIS configured with Dynamic Compression enabled
App 2
Exact copy of App 1 with Response Compression middleware
IIS configured with Dynamic Compression disabled
I confirmed both working by hitting their endpoints with Fiddler and an Accept-Encoding: gzip header. Both returned gzipped responses. IIS had the additional feature of auto-adding the Vary: Accept-Encoding header to the response. I didn't bother adding that to App 2. This was just meant to be a little quick-n-dirty test.
Result
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 ...
| App 1 (IIS) | App 2 (Middleware) |
|---|---|
| 28.22 KB/s | 21.28 KB/s |
... 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?