Accelerate Traffic — Enabling and Tuning Compression
Instructions to increase WAN-link capacity and to
tune compression options to optimize performance gains
Packeteer's Xpress 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. Specifically, Xpress:
- Compresses traffic to squeeze more data through a limited WAN link
without losing quality or data
- Accelerates application performance by getting fewer bits across the
WAN faster.
- Removes the administrative burden of having to define, configure,
and maintain compression tunnels (the mechanism used to shrink, transfer,
and restore traffic)
- Assesses real-time performance and latency data to adjust compression
and bandwidth allocation to ensure optimal performance of critical applications
For more background, see PacketGuide's
Compression Overview and the white paper titled "Accelerating
Throughput."
Enable Compression
- Compression has several prerequisites including a Packeteer Xpress
compression software key. See the section titled Requirements
in the Compression
Overview.
- No complicated setup or configuration is required to enable
compression. Once enabled, PacketWise automatically creates, configures,
and maintains compression tunnels for you.
- Examine
the results you get from your compression.
Tuning Compression for Optimal Results
Because Xpress acceleration configures compression tunnels for you, no
explicit action is required from you to use compression and get its bandwidth-saving
benefits. You can continue with the default configuration indefinitely.
But if you are not getting the gains from compression that you expected,
or if you'd like to see if you can get even better gains, consider tuning
compression's configuration for optimal results. There are several tuning
tasks you can try, or you can try them all.
Consider Policy and Partition Settings
Application performance is achieved through a combination of appropriate
shaping policies and effective compression configurations. Xpress is designed
to optimize compression gains based on policies or partitions that are
already in place. Therefore, it is typically not necessary to adjust shaping
policies for newly compressed traffic.
Use the following guidelines when configuring shaping with PacketShaper
Xpress:
Policies allocate bandwidth on a pre-compression basis.
Use the same rates in policies whether or not you have compression.
- Rate policy example
Suppose Citrix flows require 10 Kbps of uncompressed traffic to perform
well, and their rate policy is set accordingly. In addition, suppose
Xpress typically compresses the 10 Kbps down to 4 Kbps. It is not
necessary, recommended, or advantageous to adjust the Citrix rate policy's
guaranteed rate down as well.
Partitions allocate bandwidth on a post-compression basis.
Definitely leave your partition sizes that are in percentage formats as
they are. You can leave your explicit minimum and maximum partition sizes
alone and get more throughput from your same bandwidth, or you can adjust
the sizes to take anticipated gains into account.
- Partition example
Suppose HTTP traffic is limited to 150 Kbps with a fixed partition.
If Xpress delivers a 2:1 compression ratio, 300 Kbps is compressed into
the 150 Kbps partition. Without changing any settings, you send twice
the HTTP traffic in the same bandwidth. Alternatively, if you really
do want to contain HTTP traffic to 150 Kbps of original, non-compressed
content, and you have gotten consistent 2:1 results over time, you could
choose to reduce the partition size to 75 Kbps.
Give a Large, Critical Traffic Class its own Dictionary, Size, and/or
Algorithm
By adjusting the rules and settings Xpress uses for compression, you
can influence the results it gets. With each change, there are tradeoffs,
so it's best to learn a little about
compression algorithms and their dictionaries so that you can make
judicious changes. Then examine the following steps to implement changes.
- Make sure your traffic tree is sufficiently granular to identify your
critical applications. In addition, make sure your traffic tree identifies
your bursty, high-volume traffic. For example, separate web-based SAP
or Oracle traffic from other HTTP traffic.
For help, see PacketGuide instructions for Classify
Network Traffic, Identify
Mysterious Traffic, and/or Classification
Hints and Examples.
- Select your top three critical outbound applications
with the highest volume.
Only outbound traffic benefits from compression. If you have an inbound
traffic class you want compressed, you must configure the Xpress units
on the opposite end of the compression tunnel where the traffic originates
— the traffic will show in an outbound class there.
To help, you can display the top
ten pie chart or list
the top ten traffic classes, or examine the list
of top-ten-style graphs available.
- Assign each of your selected classes its own compression algorithm
and dictionary, and optionally increase the dictionaries' sizes. Access
the CLI and then use the class
compress on command.
For example, you could enter:
class compress outbound/Oracle
on override Pred2-1M 1
to give your outbound Oracle traffic its own compression dictionary
of 1 MB using the most effective compression algorithm. The "1"
is the ID for the new dictionary. You would use "2" and then
"3" for your subsequent traffic classes.
You can, of course, choose different settings, according to your goals
and the background
information about algorithms and their dictionaries that you read
earlier. For example, if you want very quick compression with high compressed
throughput but smaller compression gains, try out the Pred1 algorithm,
wait for some time, and then assess
compression results. Or, if you have a traffic class with mostly
text-based content, you could try one of the Zlib algorithms (Zlib7
offers a nice tradeoff of results and timing).
If you have two outbound classes that have similar traffic content and
compression needs, then you can assign the second traffic class to the
same dictionary by using a repeated dictionary ID parameter. For example,
suppose you have two Oracle traffic classes for your sales department's
traffic, one for Oracle traffic using the WestUS database and one for
Oracle traffic using the EastUS database. You might want to enter the
following two CLI commands:
class compress outbound/Oracle/SalesWest
on override Pred2-1M 5
class compress outbound/Oracle/SalesEast
on override Pred2-1M 5
If you want to verify your changes, try the class
show <classname> CLI command.
- Let some traffic pass that will be classified into your special traffic
classes. Your dictionary will be initialized and used. After that, you
can start to see results by creating
the graphs for some of the compression-related
graphs.
- Consider if you want to apply the same compression configuration changes
to the same classes on Xpress units at both ends of compression tunnels.
If the traffic tends to be the same in both inbound and outbound directions,
then you might want to apply changes on both ends. However, if only
one end of the compression tunnel has voluminous outbound traffic, then
changing just the one end is fine.
Adjust Packing Settings
Packet packing is the act of selectively bundling or concatenating smaller
packets into a single larger packet. Packing reduces overhead, such as
headers and acknowledgments, and can improve the gains attained in compression.
When traffic is heavy, PacketWise does not have to wait for additional
packets to pass in order to have the multiple packets required for packing.
But when traffic is light, PacketWise waits for a short amount of time
to see if any more traffic comes along that could be added before forwarding
a skimpy packet. This waiting time can add latency to pending packets.
In this case, you are giving up the speediest possible response times
for the benefit of more compression and lower traffic volumes. Xpress
does adapt waiting times according to the application. If an application
is particularly latency sensitive (such as all applications' connection
acknowledgments), a shorter packing time is used.
You can choose whether PacketWise does packet packing at all, and if
so, the maximum amount of time it can delay a pending packet while waiting
for additional traffic to bundle:
|
