Assess Compression Results

Instructions to examine your bandwidth gains due to compression

Packeteer's Xpress compression increases WAN-link throughput without imposing cumbersome administrative overhead. It makes it seem as if your WAN link offers more bandwidth than it really does.

For background on compression, see Xpress Overview.

How much bandwidth savings are you getting from compression? Follow the steps below to find out.

1. Wait some time after enabling compression or changing compression's settings to allow traffic to pass and the changes to have an effect.
   
   
2. Display the compression summary. Adjust the interval to reflect the time you are interested in evaluating. Leave the checkboxes UNchecked (the default) for including non-compressible traffic and for including the link size.
   
   Examine the numerical data in the table at the top. The Inbound statistics represent inbound traffic that gets decompressed by Xpress, and the Outbound statistics represent outbound traffic that Xpress compresses. In the Outbound column, compare Precompression Bytes to Postcompression Bytes. Was your traffic significantly smaller after compression than before? Look at the % Bytes Saved value to determine the percentage of transfered traffic that you saved.
   
   Review the graphs beneath the numerical data. They describe the same information, but give you an idea of the amount of compressed traffic and the amount of compression that took place over time. So if, for example, most of your compressible traffic is generated at certain times, you'll see that pattern on the graphs.
   
   If you see both impressive savings and large traffic volume, then much of your link's traffic is compressible, and it's working well.
   
   If you see great savings on a percentage basis, but a large volume of traffic is not portrayed, then you either had low traffic volume in general or much of your traffic was not compressible. You'll find out which in the next step.
   
   If your compression results are not up to par, then consult Compression Troubleshooting. If you want to tune Xpress for better compression results (an advanced project), see Tuning Compression.
   
   
3. Select both of the checkboxes at the top of the Compression Summary (include non-compressible traffic and include link size). Then click Update.
   
   The same table and graphs appear, but probably with different results.
   
   If the table results are very close to your previous report, then it just means that most or all of your traffic was compressible. That's great. Your whole link is getting the benefits of compression.
   
   If % Bytes Saved and Bandwidth Multiple (the percentage by which virtual bandwidth is increased due to compression) are much lower than before, it means that you had a definite amount of traffic that was not compressible.
   
   Many types of traffic are not compressible, such as VoIP, encrypted traffic, and/or traffic heading to destinations without compression-enabled PacketShapers. If much or most of your traffic is not compressible, then your savings rates in this Compression Summary will not be dramatic once all that traffic is included in the totals.
   
   The first summary you viewed portrays the effectiveness of your compression. This second summary portrays how much of your traffic benefits from compression's gains. Both figures are useful.
   
   If the colored lines in your graphs dropped so far to the bottom of the graph as to be less than helpful, it just means that your traffic volume was not high during the measured interval. The graphs scale changed in order to insert the green Link Size horizontal line. In this case, your previous summary, without link size, is more helpful.
   
   
4. If you have a large amount of non-compressible traffic, you'll want to find out why traffic wasn't compressed. An additional graph is available that provides this information. To see this graph, click the Non-compressible traffic breakdown link. (This link appears only if you have selected the include non-compressible traffic checkbox as you did in the previous step.)
   
   A new window opens, displaying the Non-Compressible Traffic line graph. This graph indicates the amount of traffic that was non-compressible due to each of the following reasons:
   • Compression Disabled — Compression was not enabled (for example, a particular tunnel had compression disabled so none of the traffic in the tunnel was compressed).
   • Traffic Policy — The traffic was classified as a non-compressible service, compression was disabled for the class or service, or the traffic was broadcast or multi-cast (only packets with unicast destination addresses are compressed).
   • System Availability — There was insufficient compression memory to tunnel the traffic or the CPU was too busy. (To see compression memory statistics, use the tunnel summary command.
     
   • No Tunnel for Host — Hosts were restricted from using compression, partners were excluded from using compression, a tunnel partner wasn't found, or hosts were not discovered.
     
     
5. Create a graph for Link Compression Bytes Transferred. This graph provides a visual impression of the tabular information at the top of your Compression Summary — the difference compression has made. This one graph supplies a very big picture. It shows traffic volume that you:
   • Would have had without compression
   • Actually did have with compression
   • Saved due to compression
   • Could not compress (VoIP, encrypted, and so on)
     
     
6. Explore the variety of other compression-related graphs for individual classes (especially your critical and high-volume classes), partitions, and the link.
   
   Note that compression results are most informative when you display a graph or chart for one particular class, and the class has only one particular type of traffic.
   
   For example, suppose you have an Outbound traffic class for POP3 that contains both standard and encrypted email. Examining compression results for that POP3 class might not be very impressive. If your organization had a sudden burst of secure email (encrypted traffic does not compress well) then your overall compression figures for email would look rather poor. But if you were to separate the POP3 class into two subordinate classes, then you could run a compression report for the standard email class and see some great results.
   
   You might have a similar pattern with other classes that contain multiple types of traffic or that contain the same type of traffic going to some destinations with compression-enabled PacketShapers and some without.
   
   If you need help or ideas in dividing your traffic tree into more granular classes, see Create an Application-Based Traffic Tree and Classification Hints and Examples.
   
   
7. Another way to assess compression results is on a per-tunnel basis. The Xpress Tunnels Overview on the Xpress tab gives per-tunnel statistics on all the enhanced tunnels that have been formed with your PacketShaper. The overview lists the Inbound and Outbound statistics for each tunnel: speed before and after compression/decompression, and percentage of bytes saved due to compression.
   
   To see how compression is working on a particular tunnel, you can compare the speed before and after compression (Outbound Pre-Comp. vs. Outbound Post-Comp) or look at the compression savings (Outbound % Saved). The statistics can be helpful, but keep in mind that the Xpress Tunnels Overview shows the average rate over the last minute. So whether your per-tunnel compression results look stellar, dismal, or somewhere in-between, they are probably not representative of your overall savings.
   
   If there is a problem with the tunnel, a warning icon will appear next to the tunnel name. See Tunnel Troubleshooting.