A simple method to optimize Ro

Regardless of the three-tier architecture, as long as the data packet is compressed, you must find the best way to compare the compression ratio to time.

RO uses zlib to compress data streams. The latest version of zlib is 1.2.3. ro also uses the latest version.

In my opinion, the compression time on the server is more important than the compression rate, especially on servers with a large number of concurrent connections.

Decompression is much faster, even about 1% of the compression time.

The cldefault compression ratio of zcompressstream is only about 10% less than that of clfastest.

Below is our practical test:

Find the following methods in the urobinmessage unit:

Zcompressstream (source, destination );

Changed:

Zcompressstream (source, destination, clfastest );

Re-compile and test. Download A 2 mb bmp file from the database to the client. The clfastest compression method is 20%-30% faster than the default method.

Never underestimate the data flow of about 2 MB. If it is just a common text + value, the data volume is tens of thousands or even 100,000 orders of magnitude.

You may be so whimsical. How many megabytes or even GB?

Sorry, there is no intermediate layer (the database query method) that allows you to download such a large data stream. Simply compressing such a large data stream will surely be overwhelmed by High-concurrency requests. If you need to have such a requirement, we recommend that you add an FTP interface on the third layer to download the file, corresponding to the transmission of large files, FTP is better than TCP.