Gzip compresses but doesn't speed up download of JSON output from a Spring MVC Rest API

Question

I have a Spring MVC Application running on tomcat 7, which returns a large ( 4 Mb) JSON response to a REST API request. Using Chrome developer tools, I traced that the download on average takes about 2.9 seconds. To speed things up and reduce data usage, I enabled gzip encoding, first using tomcat compression (and later using apache mod_deflate).

During both time, I saw the file size reduce to about 250Kb. The request headers had gzip and chunked encoding flags set. However, the network transfer time did not decrease (in fact on average, I think i saw a very small increase).

Does this make sense to you? I'm trying to figure out why the transmission speed is unchanged with the file size change. If this is insufficient information, let me know what data exactly would be good to make this question more constructive. Should I be using custom servlets with GZipOutputStream instead? (id like to know why if that's the right approach)

Answer 1

• Literraly speaking, transmission time is the time from the first bit until the last bit of a message has "left" the server.
• On the other side, propagation time is the time needed for the packet to travel in the transmission mean (air) to reach the destination.

So, if the size of the packet is smaller, then both times should decrease. However, I guess developer tools of Chrome start counting the "transmission time" from the second you made the request, since the browser cannot be aware about the moment the server starts transmitting. Thus, the transmission time you have counted includes the time the server needs to compress the files and this is the reason it is not significantly decreased.

In general, deflating (gzipping) or not the responses of a webserver is a tradeoff, that needs to be carefully investigated. Specific elements provide a lot of time gains when deflated (such as css files), while for others the wasted CPU time exceeds the time benefits (e.g. JPGs or PDFs).

Answer 2

Hardware network compression may occur transparently at a lower level of the network stack, making the gzip compression almost useless in some cases.

To verify this, you can try this little experiment. Disable gzip compression in both Tomcat and Apache. Try to download a highly compressed 4 Mb file (like a mpg or zip file) from Tomcat and note the time spent. Next, create a new file using a text editor and fill it with a repetitive string sequence, e.g. "00000" or "123123123" until it has 4 Mb. Now download that file through Tomcat and compare the time with the one of the compressed file. It will very likely download much faster than the compressed file of the same size, even though gzip compression is disabled. This is because modern network equipments often have built-in compression.

However this lower level compression depends a lot on the hardware used, the network you are on, etc. so I would still recommend to enable gzip compression. It can improve the download time for some users, although not all users.

Answer 3

If you use Tomcats or Apaches compression it will be compressed on the fly, while the download is active. This compression takes (cpu) time and therefore slows down your download. It will still be a lot faster over slow connections like mobile connections.

If you would use a precompressed file and serve that based on the requested Accept-Encoding it would be a lot faster. Both Tomcat (https://tomcat.apache.org/tomcat-9.0-doc/default-servlet.html#where) and Apache can do that, if you tell them to.