Increase Link Capacity — 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.
- Assesses real-time performance and latency data to adjust compression
and bandwidth allocation to ensure optimal performance of critical applications
For more background, see Xpress
Overview.
Enable Compression
- Little manual configuration is required to configure
and enable compression. Once enabled, PacketWise automatically creates,
configures, and maintains compression tunnels for you.
- Examine the
results you get from your compression.
Tune Compression for Optimal Results
No explicit tuning is required from you to use or configure compression
and get its bandwidth-saving benefits. Xpress compression establishes
and maintains compression tunnels for you and employs appropriate
default configuration settings. Therefore, you can continue with the default
configuration indefinitely.
However, if you have gathered some experience with Packeteer products
and would like to see if you can get even better compression gains through
tuning, you can explore some or all tuning suggestions below.
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 Compressor
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 compressors so that you can make judicious
decisions. Follow these steps to make changes.
- Select a critical outbound traffic class with high volume.
Avoid classes for traffic that is not compressible such as encrypted
or streaming applications.
Only outbound traffic benefits from compression on this unit. If you
have an inbound traffic class you want compressed, you must configure
the PacketShapers on the opposite end of the compression tunnel where
the traffic originates — the traffic will show in an outbound class
there. (However, inbound compression results are indeed displayed on
the inbound Compression Summary of this unit, even though this unit
did not compress the traffic.)
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.
- Consult Compression
Algorithms and Compressors with your selected traffic in mind.
Choose an appropriate algorithm.
- Assign your selected class its own compression algorithm.
Access
the CLI and then use the tunnel class set algorithm command.
For example, you could enter:
tunnel class set algorithm outbound/Oracle Pred2 1
to use the Pred-2 algorithm for your outbound Oracle traffic. The "1"
is the ID for the new compressor. You would use "2" and then
"3" for any subsequent traffic classes that needed their own
compressor. If each class used a different
algothrithm, they could each use the same ID number (for example, "Pred2-1M
1", "Pred2-2M 1", "Pred2-4M 1").
You can, of course, choose different settings, according to your goals
and the background information you found in earlier steps. 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, you might want to try the ICNA algorithm.
- 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 compressor by using the same algoirthm and group ID.
This would save in two ways:
- Save time in compression because data that was already shortened
and deposited in the dictionary would not have to be done again
for traffic in the different but similar traffic class
- Save memory because you you would only need one instance of the
class-specific compressor instead of two.
They would share compressors and memory.
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:
tunnel class set algorithm outbound/Oracle/SalesWest
Pred2 5
tunnel class set algorithm outbound/Oracle/SalesEast
Pred2 5
If you want to verify your changes, use the tunnel class show <tclass> CLI command.
- Let some traffic pass that will be classified into your special traffic
classes. Your compressor (Pred2_5) will be initialized and used. After that, you
can start to see results by creating
some compression-related
graphs.
- Consider if you want to apply the same compression configuration changes
to the same classes on PacketShapers 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 can adapt waiting times according to the application. For instance, Telnet and ICMP are time sensitive, so these services have a 0 ms packing wait time. On the other hand, POP3-Clear and SMTP-Clear are not sensitive to delays, so these email services have a 100ms packing wait time.
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:
Something Isn't Right
If your compression isn't performing to expectations (see Assess
Compression Results to verify), consult Compression
Troubleshooting.
|
