search

aspnet / BasicMiddleware

[Archived] Basic middleware components for ASP.NET Core. Project moved to https://github.com/aspnet/AspNetCore
Apache License 2.0
169 stars 84 forks source link

A question of speed with Response Compression Middleware #179

Closed guardrex closed 5 years ago

guardrex commented 7 years ago

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?

Tratcher commented 7 years ago

I suggest also testing kestrel+middleware without IIS.

Tratcher commented 7 years ago

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 (https://github.com/dotnet/corefx/issues/12549).

guardrex commented 7 years ago

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.

KB/s

Run App 1 (IIS) App 2 (MW on IIS) App 2 (MW on Kestrel)
1 392 305 304
2 324 252 251
3 315 245 245
4 311 242 242
5 314 244 244
Avg 331 258 257
SD 34 27 26
davidfowl commented 7 years ago

Re-opening this.

/cc @mikeharder Another middleware to add to the benchmarks.

muratg commented 6 years ago

@sebastienros is this something in your queue already?

sebastienros commented 6 years ago

@muratg Was not aware of this issue. Do we need to track the results or just have a a new snapshot?

Tratcher commented 6 years ago

Tracking is optional, most of the perf is controlled by IIS and corefx. We primarily want to know how the perf of corefx compares to that of IIS/Express for dynamic compression.

speige commented 6 years ago

+1

aspnet-hello commented 5 years ago

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.