Principle IntroductionHTTP compression can greatly improve the speed of browsing the site, it is the principle that after the client requests the server corresponding resources, from the server side of the resource file compression, and then output to the client, by the client's browser is responsible for extracting and browsing. Relative to the normal browsing process HTML, css,javascript, Text, it can save about 40% of the traffic. More importantly, it can be dynamically generated, including CGI, PHP, JSP, ASP, servlet,shtml and other output of the Web page can also be compressed, compression efficiency is very high.
Configuration MethodLater versions of Tomcat5.0 support the compression of the output, using the GZIP compression format. To modify the%tomcat_home%/conf/server.xml, the revision node is as follows:
[XHTML]View Plaincopy
- <Connector port= "protocol=" http/1.1 "
- connectiontimeout="20000"
- redirectport= "8443" executor="Tomcatthreadpool" uriencoding= "utf-8 "
- compression="on"
- compressionminsize= "nocompressionuseragents=" Gozilla, Traviata "
- compressablemimetype="Text/html,text/xml,text/javascript,text/css,text/plain" />
As you can see from the properties of the above node, to use the gzip compression feature, you need to add the following attribute to the connector node
- Compression= "On" to turn on the compression function
- Compressionminsize= "50" enables compressed output content size, default is 2KB
- Nocompressionuseragents= "Gozilla, Traviata" for the following browsers, do not enable compression
- Compressablemimetype= "Text/html,text/xml,text/javascript,text/css,text/plain" which resource types need to be compressed
For some text files such as: Log, TXT and other files, we can also allow the server to use gzip compression transmission, modify the Conf directory of Web. XML, add
<mime-mapping>
<extension>log</extension>
<mime-type>text/plain</mime-type>
</mime-mapping>
And so on, you can specify the compression transfer. Typically, compression transfers can significantly increase the display speed.
The consequences of both nginx and Tomcat enabling gzip:
http://www.iteye.com/topic/1118087
New deployment of a server in the performance tuning after the discovery of FCK online editor ie, Firefox has errors, only chrome normal. Think of the solution, almost the FCK replaced. After a lot of hardships finally found the reason (I find the reason for the bad luck has been very good):
began to think that the script is garbled, read the file header of the comment after the confirmation is not the problem.
In the Firefox firedebug above the script has been reported to find no object error, is the company's network turtle speed caused by the script loading order uncoordinated caused? After several refreshes the problem is still, 304 status code description is not the reason of the network turtle speed.
Finally the FCK JavaScript script downloaded to the local later, only about 20k, and the complete is 249K, it seems I found the reason ~ ~
Still baffled, good static script file Why did you download a part of it? And the first download of the status code is 200, after the refresh is 304, which violates my understanding of the HTTP status code.
Aside from the front-end nginx, direct access to Tomcat incredibly page is normal. so~ problem in Nginx. Nginx's ability to handle static resources has never been doubted (this again violates my understanding of XXX).
A flash of light, the front and back of the server has recently been tuned, is this the modification of the configuration file caused? So first off the Nginx gzip off, restart Nginx after the world normal. Then turn off back-end tomcat compression= "off", re-enable Nginx gzip, the problem finally solved.
Summary: System-enabled gzip compression for multi-tiered server architecture to be aware of a problem: after the front-end server is enabled for gzip, the backend server does not enable gzip compression, or some browsers will download to incomplete files.
test MethodWith the Tomcat feature enabled, how do we test whether compression works? First, Tomcat determines whether the browser supports compression based on the accept-encoding in the browser's request header, and if the value contains gzip, which indicates that the browser supports GZIP-compressed content browsing, there are two ways to verify that compression is in effect.
direct request via browserEveryone directly through the browser to access the server with the compression configuration, and then through the capture tool to see the captured packets, if there is a lot of content you do not understand, it means that the compression function has been enabled.
simulate a request through a programWe use HttpClient to write a simple test program, the code is as follows:
[Java]View Plaincopy
- @Test
- Public void Testgzip () {
- HttpClient HttpClient = new HttpClient ();
- GetMethod GetMethod = new GetMethod ("http://localhost/admin.jsp");
- try {
- Getmethod.addrequestheader ("accept-encoding", "gzip,deflate");
- Getmethod.addrequestheader ("user-agent","mozilla/4.0" (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar; Maxthon 2.0) ");
- int result = Httpclient.executemethod (GetMethod);
- if (result = = ) {
- System.out.println (Getmethod.getresponsecontentlength ());
- String html = getmethod.getresponsebodyasstring ();
- SYSTEM.OUT.PRINTLN (HTML);
- System.out.println (Html.getbytes (). length);
- }
- } catch (HttpException e) {
- E.printstacktrace ();
- } catch (IOException e) {
- E.printstacktrace ();
- } finally {
- Getmethod.releaseconnection ();
- }
- }
Execute this junit program, see what it is output, if the output is some garbled, and the length of the printed content is far less than the actual length, it means that our configuration is in effect, through some other verification tools, you will find that the site browsing speed significantly increased. Note: If you find that the content is not compressed, you can consider resizing the compressionminsize, if the requested resource is less than this value, compression is not enabled.
Set up Tomcat to enable gzip compression