3

In start up class , I added the below line to my asp.net core application

services.AddResponseCompression();

so configureServices method is looked like below

  public void ConfigureServices(IServiceCollection services)
        {
            services.AddDbContext<MyDBContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

            services.AddCors(options =>
            {
                options.AddPolicy("AllowAll",
                    builder =>
                    {
                        builder
                        .AllowAnyOrigin()
                        .AllowAnyMethod()
                        .AllowAnyHeader();
                    });
            });
            services.AddMvc();

            services.AddResponseCompression();

        }

and also I added the below line to configure method

 app.UseResponseCompression();

here is configure method

 public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
          if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseCors("AllowAll");
            app.UseResponseCompression();
            app.UseMvc();
        }

now when I run the project , it works faster , size of response has been reduced and compressed (I checked it via chrome console Network tab ), it is the purpose of response compression Middleware to compress the response

My question is : Is there any cons of using this Middleware or Is there any situation that I should not use response compression ?

Bassem
  • 221
  • 1
  • 3
  • 13

2 Answers2

6

Advantages

  • Compressing contents helps with decreasing the time it will take for client to download.
  • It saves your bandwidth so it reduces costs !

Disadvantages

  • Compressing contents eats your server’s CPU cycles !
  • Decompressing eats your clients CPU cycles as well (@Evk)
programtreasures
  • 4,250
  • 1
  • 10
  • 29
  • 1
    Also decompressing eats your clients CPU cycles as well – Evk Dec 26 '17 at 13:33
  • Doesn't this compression middleware work with complete stream so your whole response will be in memory as well rather then sending it part by part? – Filip Cordas Dec 26 '17 at 13:33
  • Another advantage is that it saves client bandwidth as well as server's. As a disadvantage, it requires client compatibility or else the site doesn't works at all. – Alejandro Dec 26 '17 at 14:37
  • 1
    @Alejandro the way compression works - is that it's automatically enabled only when the client browser supports it, according to the accept-encoding request header. – Effy Teva Aug 26 '20 at 12:01
6

Ok after some investigating there seam to be some changes since dot.net core 2. First of all UseResponseCompression should be used as a last option or in other words

Use Response Compression Middleware when you're:

Unable to use the following server-based compression technologies:

  • IIS Dynamic Compression module
  • Apache mod_deflate module
  • NGINX Compression and Decompression

Hosting directly on:

  • HTTP.sys server (formerly called WebListener)
  • Kestrel

Source

And hosting on Kestrel is only recommended for high performance api endpoints, For public facing endpoints you should run under IIS so use the native compression and not the middleware.

When it comes out of the box Gzip compression for the middleware this use to perform really bad and tended to slow down the total round trip time rather then improve it especially for small payloads. From what I can see they changed the implementation for .net standard 2.0 and I am not sure how well it will work.

But when you are talking about compression it really depends on the use case so you should do performance testing with loads you expect and setup you have and see if you get any improvements.

For general info on the subject of gzip you should look at this other question

Filip Cordas
  • 2,531
  • 1
  • 12
  • 23