GZIP compression Tomcat and improve web performance process diagram

1. Introduction

I recently worked on a project and encountered a problem: the amount of JSON data returned by the server to the client was too large (about 65M), and it took more than a minute to load and render on the client (of course, this loading time is also related to the local downstream bandwidth), which was time-consuming and consumed a lot of traffic, and the user experience was extremely bad. Later, I searched online for an optimization method, which turned out to be Http compression.

HTTP compression can greatly improve the speed of browsing websites. Its principle is that after the client requests the corresponding resources from the server, the resource file is compressed from the server and then output to the client. The client's browser is responsible for decompressing and browsing. That is: reduce the response time by reducing the HTTP response size. Compared with the normal browsing process HTML, CSS, Javascript, Text, it can save about 40% of the traffic. More importantly, it can compress dynamically generated web pages, including those output by CGI, PHP, JSP, ASP, Servlet, SHTML, etc., and the compression efficiency is also very high. GZIP itself is a network stream compression algorithm and is widely used. This article is about configuring GZIP compression for Apache Tomcat 8.0.47. The browser used is Mozilla Firefox 35.0.1, and the built-in Firebug is used for debugging. The following network-related screenshots are from the Firebug console.

2. Introduction to Gzip Compression

1. The HTTP protocol supports the GZIP compression mechanism, also known as protocol compression. HTTP GZIP compression is a protocol that is followed by both the web server and the browser, which means that both the web server and the browser must comply with it. Currently, mainstream servers and browsers support GZIP compression technology. Including Chrome, IE, FireFox, Opera, etc.; servers include tomcat, Apache and IIS, etc.

2. GZIP is mainly used to compress static text files such as html, css, javascript, etc. It also supports compression of dynamically generated web pages, including those output by CGI, PHP, JSP, ASP, Servlet, SHTML, etc.

3. The GZIP compression ratio is usually between 3 and 10 times, which can greatly save the server's network bandwidth and greatly improve the browser's browsing speed.

4. GZIP is a data compression format. By default, it only uses the deflate algorithm to compress the data part. Deflate is a compression algorithm that is an enhancement of the Huffman code.

5. Protocol compression is based on the HTTP protocol. Programmers do not need to perform compression, decompression and encoding. Instead, the compression process is handed over to the WEB server and the decompression process is handed over to the client. If the client is a browser that supports GZIP compression, the decompression process does not require the programmer to participate, and the browser will automatically decompress according to certain rules; if the client is HttpClient, then GZIP decoding needs to be performed manually.

6. Compression process: The client sends an http request. If the request header carries Accept-Encoding:gzip,deflate (current browsers generally use this as the default), the browser means that the server needs to perform GZIP compression, and then see if the response content type meets the compression type configured by the server. If so, the WEB server will compress the response content before transmitting it, and add Content-Encoding gzip to the response header; if not, it will not be compressed and will be returned directly.

7. Decompression process: (Browser) The client receives the response. If the response header contains Content-Encoding GZIP, the browser will automatically decompress the response content using GZIP and then present it on the page. If not included, it will be rendered directly on the page.

8. Disadvantages of GZIP. Compared with projects without GZIP, using GZIP will increase the pressure of server compression (CPU consumption) and client decompression, so the configuration requirements of the server are higher. In addition, compression also takes time. If you want to occupy less space and get a high compression ratio, you must sacrifice a longer time. On the contrary, if time is more precious and speed is required, then the compression ratio must be smaller, and of course it will take up more space (compression ratio = original content size/compressed size, the larger the compression ratio, the smaller the compressed package occupies after compression). This is the contradiction between physical space and time.

3. Configuration method in tomcat

Version requirement: Tomcat 5.0 or above. Modify %TOMCAT_HOME%/conf/server.xml and revise the nodes as follows:

<Connector port="8080"
protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
compression="on"
compressionMinSize="2048"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml,text/javascript,
application/javascript,text/css,text/plain,text/json"/>

Parameter Description:

1. compression="on" turns on compression. Optional values: "on" to enable, "off" to disable, "force" to enable in all cases.

2. compressionMinSize="2048" Only files larger than 2KB will be compressed. Used to specify the minimum compressed data size, in B, with a default value of 2048B. Pay attention to the size of this value. If it is not configured properly, the result will be that small files will become larger after compression, which will not achieve the expected effect.

3. noCompressionUserAgents="gozilla, traviata", for these two browsers, no compression is performed (I don’t know what these two browsers are, and I can’t find them on Baidu). Its value is a regular expression, and the matching UA will not be compressed. The default value is empty.

4. compressibleMimeType="text/html,text/xml,application/javascript,text/css,text/plain,text/json" is a list of MIME types that will be compressed. Multiple types are separated by commas, indicating that compression of file formats such as html, xml, js, css, and json is supported (plain means no format, but I am vague about what it is). compressableMimeType is very important. It is used to tell Tomcat which file to compress. If the type is specified incorrectly, it will definitely not be compressed. So, how do you know what file types to compress? This can be found by the following method.

4. Check whether the configuration is successful

After the modification, restart tomcat, and finally go to the test website: http://seo.chinaz.com/?host=iitshare.com to check the effect

5. Common errors (no effect after configuration)

You can troubleshoot by following the steps below:

1. The configuration parameters in tomcat are written in the wrong location. Note that the configuration parameters should be written to area A in the figure below instead of area B, that is, the Connector with protocol="HTTP/1.1".

2. The response data is not of the type configured by the compressibleMimeType parameter. I encountered this pit. Our project used json for front-end and back-end transmission. So I initially thought it was "text/json", but then I opened the Firebug console and found that the value of Content-Type was "application/json". See Figure 3.

3. The size of the response data is smaller than the configuration value of compressionMinSize.

Appendix: Optimization results

It can be seen that the compression ratio = 65.6 / 8.4 = 7.810, the time ratio = 96 / 16.2 = 5.926, which is already ideal.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.