Shulou(Shulou.com)06/02 Report--

It is believed that many inexperienced people are at a loss about how to compress in Java performance optimization. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Compress

In micro-service invocation, if the incoming content is too long, compression is a good way to improve the transmission speed. There are many ways to compress. One way is to adjust the attribute name of the transmission object to minimize the transmission message size, which is more suitable for transmission JSON or XML, such as

Public class OrderRequest {private String orderId; private String userId;}

If you use JSON transport, the content is

{"orderId": xxx, "userId": yyyyy}

Can be adjusted to

Public class OrderRequest {private String oid; private String uid;}

Using JSON to transmit {"oid": xxx, "uid": yyyyy}, this adjustment obviously makes the size of the transmission message a little smaller. You can also merge some fields of the transfer object, such as "order status", "user status" and "test order" into an int type, and distinguish the status by "bit".

Public class OrderRequest {/ / user status private int userStatus; / / order status private int orderStatus; / / Test order private int testFlag}

Change it to the following, and you need to obtain the status of the order through bit operation.

The public class OrderRequest {/ * 0 bit indicates whether to test the order, the 1-4 bit indicates the user status, and the 5-8 bit indicates the order status * / int s; public boolean isTest () {/ / take out the first bit value return (status&0b1) = = 1 } public int getUserStatus () {/ / move 1 to the right, take out the value of 1-4 bits return (status > > 1&0b1111);} public int getOrderStatus () {/ / move 5 to the right, take out the value return of 5-8 bits (status > > 5&0b1111);}}

In this way, OrderRequest would need 3 int types, a total of 12 bytes to save the order status, now only 4 bytes can be saved. If there are more states, they can also be represented by the remaining bits of the s value. For example, a new status for an order indicates whether it contains a large item, which can be expressed as bit 9.

Public boolean isLargeProduct () {return (status > > 9&0b1) = = 1;}

If the s value is 0b1_0100_0110_1 (corresponding to decimal 653), then isTest returns true,getUerStatus returns 6 Magi getOrderStatus returns 4 Magi isLargeProduct returns true

Another compression method is to compress on the transport protocol. For example, JSON is more economical than XML, and using MessagePack is more space-saving than JSON. The usage of MessagePack will be described in detail in Chapter 5.

When there is too much content, you can consider compressing the content. Compressing and retransmitting the content has the following benefits

After compression, the bytes transmitted by the network are reduced, the bandwidth is saved, and the network can transmit more content at the same time.

Network transmission is more time-consuming than compression. Especially in the current distributed system, the server is very cheap and can be expanded indefinitely, from dozens of servers to tens of thousands of services. however, the bandwidth is limited and expensive, and the bandwidth of some enterprise private networks is only 1m, which is very small.

Compression has a variety of algorithms, will output different compression ratio content, and compression time is not the same, this section selects zip, for 5K Magi 20K Magi 100k to do a performance test. Generally speaking, the greater the compression ratio, the more time-consuming. In the actual distributed system call, we need to determine what kind of compression algorithm to use according to the business requirements.

Compression uses the Deflater class in the zip package that comes with JDK, providing the fastest compression BEST_SPEED (value 1), maximum compression ratio BEST_COMPRESSION (value 9), and default compression DEFAULT_COMPRESSION (value-1)

/ / ZipUtil.javapublic static byte [] zip (byte [] bs) throws IOException {return compress (bs,DEFAULT_COMPRESSION);} public static byte [] compress (byte [] input, int compressionLevel) throws IOException {/ / zip Compression Deflater compressor = new Deflater (compressionLevel, false) / / compressed content compressor.setInput (input / / compressed end compressor.finish (); / / get compressed content ByteArrayOutputStream bao = new ByteArrayOutputStream (); / / A buffer byte [] readBuffer = new byte [1024] Int readCount = 0; / / if the content is compressed, loop while (! compressor.finished ()) {readCount = compressor.deflate (readBuffer); if (readCount > 0) {bao.write (readBuffer, 0, readCount) }} compressor.end (); return bao.toByteArray ();}

A 100k message can be tested. For the three compression ratios, the following data show that the default compression level of ZIP is good enough. After DEFAULT_COMPRESSION compression, it is 34.8k. BEST_SPEED compression is 39K. BEST_COMPRESSION compression is 34.7k.

In order to test the compression performance, the Content tool class is used to generate 5K, 20K and 100K messages respectively for testing, and the default compression, the fastest compression and the best compression are tested respectively.

/ ZipTest.javabyte [] K5 = null;byte [] K20 = null;byte [] K100 = null;// default, fastest, it is best to compress @ Param ({"- 1", "1", "9"}) int level;@Setuppublic void init () {Content content = new Content (); this.k5 = content.genContentBySize (1000 * 5); this.k20 = content.genContentBySize (1000 * 20); this.k100 = content.genContentBySize (1000 * 100) } @ Benchmarkpublic byte [] K5 () throws IOException {return ZipUtil.compress (K5, level);} @ Benchmarkpublic byte [] K20 () throws IOException {return ZipUtil.compress (K20, level);} @ Benchmarkpublic byte [] K100 () throws IOException {return ZipUtil.compress (K100, level);}

The JMH test results are as follows. You can see that even if the content of the 20K message, the compression speed is still very fast. In less than a millisecond. 100K messages take a long time, and the default compression (- 1) takes about 4 milliseconds.

Benchmark (level) Score Score error Units c.i.c.c.ZipTest.k100-1 4.467 0.233 ms/op c.i.c.c.ZipTest.k100 1 1.773 0.097 ms/op c.i.c.c.ZipTest.k100 9 5.028 0.152 ms/op c.i.c.c.ZipTest.k20 -1 0.571 0.016 ms/op c.i.c.c.ZipTest.k20 1 0.310 0.010 ms/op c.i.c.c.ZipTest.k20 9 0.592 0.023 ms/op c.i.c.c.ZipTest.k5-1 0.157 0.008 ms/op c.i.c .c.ZipTest.k5 1 0.112 0.005 ms/op c.i.c.c.ZipTest.k5 9 0.151 0.003 ms/op

This test uses an article as the compressed content. You need to do the compression test with a real message according to your business situation. In fact, if it is a XML or JSON message, it has a very large compression ratio.

This section chooses zip compression, and there are other optional methods, such as gzip,bzip2,7z, etc., you can use open source library Apache Commons Compress for compression. After the author's test, I found that zip is still a good compression ratio and performance. 7z has the largest compression ratio, but the compression time is more than 100 milliseconds, which is unacceptable in real-time business systems.

For decompression, no matter what compression method or level of compression is used, the time required for decompression is very small.

After reading the above, have you mastered how to compress in Java performance optimization? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.