This document describes the possible benefits in performance when compressing HTML files over a PPP modem line. See also the investigation on how compression affects transport on a LAN. The purpose of the test is to show the impact of using deflate on a HTML message body and see if this is worth doing on top of normal modem compression.
The compression is done using the zlib compression algorithm and the test is done on the toppage of the microscape web site which was part of the test performed in the paper "Network Performance Effects of HTTP/1.1, CSS1, and PNG". We performed the HTML retrieval only with no embedded objects. In HTTP, this is equivalent to 1 GET request.
Note that we only download the HTML page and not any of the following images. The size of the uncompressed HTML page is 42K HTML and the compressed was 11K. This means that we decrease the overall payload with about 31K or 73.8%.
I need some pointers here - I am not sure exactly what of which algorithms, a standard 28.8 modem uses.
In our test case we observed a gain in time relative to number of TCP packets as follows:
| Jigsaw | Apache | |||
|---|---|---|---|---|
| Packets | Time [sec] | Packets | Time [sec] | |
| Uncompressed HTML | 12.21 |
12.13 |
||
| Compressed HTML | 4.35 |
4.43 |
||
| Saved using compression | 68.7% |
64.4% |
68.7% |
64.5% |
The table shows very similar data for both Jigsaw and Apache - around 2/3 saved in both packet count and time. Noting that the first TCP packets are more important than later ones, based on these figures, the gain of using compression is substantial.
The result may depend on how the modem performs compression and may vary depending on the size of the HTML object. However, we believe that the effect of HTTP message body compression will be positive on a PPP modem line.
This test does not take into account the time it takes to compress an HTML object on the fly and whether this will take longer than the time gained transferring less bytes. Decompression is done on the fly by the client.