Enabling compression for one or all connections, and setting the minimum size at which packets are compressed, can improve SQL Anywhere performance in some circumstances.
To determine if enabling compression will help in your particular situation, it is recommended that you conduct a performance analysis on your particular network and using your particular application before using communication compression in a production environment. Performance results will vary according to the type of network you are using, your applications, and the data you transfer.
The most basic way of tuning compression is as simple as enabling or disabling the Compression (COMP) connection parameter on either the connection or server level. More advanced fine tuning of compression performance is available by adjusting the CompressionThreshold (COMPTH) connection parameter.
Enabling compression increases the quantity of information stored in data packets, thereby reducing the number of packets required to transmit a particular set of data. By reducing the number of packets, the data can be transmitted more quickly.
Enabling compression for a connection (or all connections) can significantly improve SQL Anywhere performance under some circumstances, including:
When used over slow networks such as some wireless networks, some modems, serial links and some WANs.
When used in conjunction with SQL Anywhere encryption over a slow network with built-in compression, since packets are compressed before they are encrypted.
Enabling compression, however, can sometimes also cause slower performance. For instance:
Communication compression uses more memory and more CPU. It may cause slower performance, especially for LANs and other fast networks.
Most modems and some slow networks already have built-in compression. In these cases, SQL Anywhere communication compression will not likely provide additional performance benefits unless you are also encrypting the data.
You can also adjust the compression threshold to improve SQL Anywhere performance. For most networks, the compression threshold does not need to be changed.
When compression is enabled, individual packets may or may not be compressed, depending on their size. For example, SQL Anywhere does not compress packets smaller than the compression threshold, even if communication compression is enabled. As well, small packets (less than about 100 bytes) usually do not compress at all. Since CPU time is required to compress packets, attempting to compress small packets could actually decrease performance.
Generally speaking, lowering the compression threshold value may improve performance on very slow networks, while raising the compression threshold may improve performance by reducing CPU usage. However, since lowering the compression threshold value will increase CPU usage on both the client and server, a performance analysis should be done to determine whether changing the compression threshold is beneficial.
Enable communication compression.
Large data transfers with highly compressible data and larger packet sizes tend to get the best compression rates.
Adjust the CompressionThreshold setting.
Lowering the compression threshold value may improve performance on very slow networks, while raising the compression threshold may improve performance by reducing CPU usage.
For more information about adjusting the CompressionThreshold (COMPTH) connection parameter, see CompressionThreshold connection parameter [COMPTH], and -pt server option.
|Discuss this page in DocCommentXchange.
Send feedback about this page using email.
|Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1|