The compression conundrum: How to measure what’s really happening

The compression conundrum: How to measure what’s really happening

Over the course of testing, we had to make several passes at testing how these application-acceleration devices use compression to move the packets along the wire faster.

Initially, we tried testing with dial-up, cable/DSL and LAN users set up in a ratio of 40-to-40-to-20, respectively. This didn’t work at all as far as compression was concerned. Transaction rates of these devices fell and response times rose when we used compression.

Part of the problem was that our traffic load was based on the number of users in each class, rather than the number of transactions each user requested. Because LAN traffic runs at a far higher rate than dial-up or cable/DSL traffic, most of the traffic outstanding was from LAN clients, for whom compression offers no benefit.

However, that’s not the whole story. The Citrix, Crescendo, F5 and Juniper products all offer the ability to apply HTTP compression selectively, such as only to those client subnets with dial-up or cable/DSL users. Thus, these products did not attempt to compress LAN traffic. Even so, response times were higher without compression than with it. (With Array’s system, HTTP compression is either on of off; it cannot apply this feature selectively.)

Hoping to show some benefit from compression, we scaled back the test so that we used only dial-up and cable/DSL users, with no LAN traffic. Here, HTTP compression really did reduce response times, but only in some cases.

Results may vary | Return: Comparison of each box tested >