Do you want to save 80% of your bandwidth to your search provider? Do you want to deliver content to your users faster? With this one trick you can!

This shows a graph showing approximately 80% reductions in data in and out of an Azure service

As shown in the graphic above, using this trick we reduced the amount of bandwidth we consumed by 80%!

Problem

I’ve found backend services communicating without compression a few times in my career. Lack of compression is an issue because it is mostly invisible. When you interact with a RESTful API through a browser, you can see whether compression is occurring in the developer tools. Those calls that your back-end services are making are opaque unless you are intercepting the traffic with Fiddler.

At a previous employer, I was informed of a compression issue because the shared on-call phone was going off at around 2 AM in the morning. After some investigation, we learned that our search provider would sometimes return large result sets. When this happened to a few customers during a period of low traffic, the issue would set off ALL THE ALERTS. The alerts were not good for my mental health because low traffic times happened in the middle of the night. We ended up adding compression, we saved a fortune on bandwidth, and our customers were better off as well.

The most recent example is when I found a compression issue here at RIMdev. We love using Elasticsearch because it enables high-value scenarios that our users appreciate. One day I was attempting to optimize some queries while I had Fiddler open. I noticed that the results from Elasticsearch were not compressed. In some instances, we were getting results that were 400kb and could take more than a second to transfer! By enabling compression, we shaved more than a second off of response times while reducing the data transferred between the app and data center by ~80%.

The Trick for Compressing Elasticsearch Responses

To solve this issue at RIMdev, we used this code to enable compression for the Elasticsearch C# client, NEST.

var settings = new ConnectionSettings(connectionPool)
    .EnableHttpCompression() // this line enables http compression!
    // a lot of other settings
    ;
    
return settings;

I told you it was ONE SIMPLE TRICK! You may have to configure your Elasticsearch cluster to compress results, but it just worked for us. We are ready to help you in the comments if you any questions or concerns.

Bottom Line

Debug your services occasionally with Fiddler. Open and watch the network traffic your applications produce. You might find low hanging optimizations with high impact results!

Published Oct 18, 2018 by

Development

Elasticsearch

Debugging

CSS Only Dropdown Menu

Welcome New Hire: Getting started in Frontend at ...

Tab Colors in Azure Data Studio

Platform UI background image and gradient utilities

Vue 3 is official

Defaulting ASP.NET Core 3.1 To Require Authentica...

Customizing VueJS components with scoped slots

Swagger Grouping With Controller Name Fallback Us...

ASP.NET Core 3.1: Newtonsoft.Json Issues With Enu...

ASP.NET Core 3.1: Default System.Text.Json Settin...

CSS Only Tooltip for All Screen Sizes

Elasticsearch With NEST Using C# nameof Not Working

How to avoid NullReferenceException in C#

Getting Started Testing Vue Components

How ConveyUX Can Convey Good Ideas

Running Database Migrations On Web Application St...

Building ASP.NET Core 3.1 Apps To Organizational ...

What Works and What Doesn't With ConfigurationMan...

Regex Performance With and Without RegexOptions.C...

z-index Is Confusing, but It Doesn't Have to Be

No Compression Leads To Bad Impression

Problem

The Trick for Compressing Elasticsearch Responses

Bottom Line

Comments

No Compression Leads To Bad Impression

Problem

The Trick for Compressing Elasticsearch Responses

Bottom Line

Using Environment Variables with Jekyll, Vue.js, and Netlify

Working With Nested Aggregates Using NEST and Elasticsearch

IE Still Breaking Promises... Literally

Random Vue Tips

The Mouse Is Not My Friend

Let’s drop the world wide web

Comments