BENEFITS OF COMPRESSION IN HTTP APPLIED TO CACHING ARCHITECTURES

BENEFITS OF COMPRESSION IN HTTP APPLIED TO CACHING ARCHITECTURES

Dr. Juan Ramon Velasco
Luis Alberto Velasco Luciañez
Grupo de Sistemas Inteligentes – DIT
Universidad Politecnica de Madrid

ABSTRACT

One of the most interesting features, which may be added to a production cache involved inside a network of co-ordinated caches, is real-time compression capability.

By doing so, the performance of the cache server will be enhanced and this may add interesting possibilities in order to achieve better results and providing a better service to our clients.

This work will try to present the general guidelines that may apply to any cache architecture meant to work with on-line compression/decompression techniques.

INTRODUCTION

Working with network applications involves dealing with the problem of improving the availability of remote resources by reducing the delays that may affect this availability.

This problem becomes especially important if low bandwidth or high latency links are involved in our communications infrastructure generating unbearable bottlenecks. Improving existing communications infrastructures to remove the bottlenecks will solve the problem but this process is very expensive. In fact bandwidth has become the most precious resource in real network applications. This means that every effort made on improving the performance of the links while keeping the costs low will be worth.

Co-operative caching networks are probably the best approach to solve the problem and are providing very interesting solutions. Compression appears as an add-on that may be applied to caching architectures in order to obtain better performance.

Applying compression to a link between two nodes with low bandwidth and usually high latency will minimise the traffic generated between the two nodes. Compression and de-compression processes will add some latency but will produce great benefits in terms of reducing the delay in the connection. This link will have an average transfer rate so the transfer time of an object of N bytes compressed into M bytes will be reduced by an M/N ratio. The number of packets will be reduced by the same ratio so the likelihood of lost packets and retransmissions will also be reduced. In addition the likelihood of disordered packets will also decrease.

So in general terms it is possible to say that the delay time produced by the decompression processes is negligible compared to the reduction in the transmission time achieved.

Network architectures main purpose is to increment the availability in terms of time of remote resources while maintaining an elevate grade of transparency that allows the user to obtain resources at the least possible effort. So the use of compression in Network applications is going to be almost the contrary of the common use. While compression is normally used to minimise the usage of the storage size generating a decrease in the availability of the resources, Network applications are going to use compression to produce a better availability.

COMPRESSION

Briefly, compression is a process by means of which the size of a data object is reduced. This process must be reversible so it is possible to obtain the original data whenever it is needed.

Provided a good compression ratio is achieved in some content types, there are some benefits that may be expected:

As it is possible to transfer the same data in less time (the size has been minimised), the link will be able to serve more users if necessary or serve the same number of users with better quality. At the end of the day if all the users of a link use compression capabilities, they will see a great improvement in the quality of the service. From queuing theory and in general from real systems it is possible to say that if the average time of service is reduced, the waiting time will be also be reduced by a factor depending on the type of distribution of the demand.

Reduce the Storage Size both in http servers and Proxy cache servers. Nowadays, disk storage is pretty cheap so there should be no worry about this matter but anyway, this is a positive effect.

Proxy caches usually have as many objects as possible stored in the assigned memory to avoid un-necessary disk access (that may slow down the service time). If we have compressed objects in memory it will be possible to have more objects in memory and the likelihood of disk access will be smaller. Although memory prices have also gone down, they are still an important factor (specially in Sun Architectures and other propietary Architectures).

Security. Compressed data is almost free redundancy data. So applying some simple crypt is pretty easy with good results.

A standard protocol is about substitute the old HTTP 1.0. One of the main features of HTTP1.1 is the use of pipelining. It is obvious that if more embedded objects are received inside each packet of html text, it will be possible to produce a better pipelining where more objects are pipelined together in the same connection. In fact, http1.1 provides a especial field to be used to send compressed data through http while maintaining all the capabilities of direct use of data by the browser or the helper applications.

ANALYSIS OF WEB CONTENT

The first approach to the possibility of applying compression to caching architectures is analysing the content that is served by these network applications. It would be especially meaningful extracting some information about which contents may benefit of compression and the ratios that may be achieved.

Figure 2

In order to be able to measure these variables in a controlled environment the cache server run at our department (Grupo de Sistemas Inteligentes de la Universidad Politecnica de Madrid http://www.gsi.dit.upm.es ) has been used. This cache is involved in a co-operative project run by CSIC (Consejo Superior de Investigaciones Cientificas http://www.rediris.es/si/cache ) an is connected in a cache network of Spain and other countries as shown in the Figure 2.

40-50 users currently use this cache with an average number of diary request of about 10,000. Surely, the sample size is not very big but analysing the data stored in the cache will serve the purpose of detecting which type of contents will benefit from the usage of compression in cache architectures.

Analysing the data stored and requested in the cache during a week it was possible to obtain some graphics of the distribution of the different content types as shown in figure 3. The most noticeable thing of this graphic is that GIF, HTML and JPEG files are the most representative content types that may be found in web pages nowadays.

Figure 3

At the same time it was analysed the benefits that were achieved in terms of compression ratios on each content type. From the graphics and statistical data presented in Figure 4, it is possible to assess that the use of compression in cache server architectures is feasible provided that use is selective with only several types of files.

The data and compression ratios appearing in these graphics were obtaining with an algorithm library called LZOP [MARKUS].

Figure 4

Analysing the distribution of objects inside the cache server studied, there are several conclusions may be extracted. From the objects suitable for compression only HTML pages seem to maintain a high grade of representation.

Besides, HTML pages are especially good for compression because they usually embed objects (Usually at least 3-4 objects are embedded inside each HTML object). So apart from the usual benefits that compression will give in the download of the object itself. The download time of the object will also affect the embedded objects, so the overall download time will be reduced in a more effective way.

COMPRESSION OF HTML FILES UNDER DIFFERENT MODELS AND LINKS

It is turn to calculate the quantity benefits that can be expected from using compression on HTML pages in links with different speed.

The idea is to evaluate of the improvement in the performance of a link in function of its transfer rate. Said in other terms, the goal is to detect which links are suitable to obtain benefits from compression on HTML pages.

Two main configurations can be expected in a cache server architecture (or in general in any architecture).

-Objects are compressed in advance. The main characteristic of this type of architecture is that the files are stored compressed in advance. That is why there is no need of decompression and things can work extremely fast. This system could be implemented in cache system for inter-cache traffic in co-operative schemes, so the objects are only decompressed when sent to the user and they are only compressed when being fetched directly from the source.

-Objects need compression before entering the link. In this case the objects are not pre-compressed and they need to be compressed before using the link, this will add some delays and the idea of this test is estimate the delays that can appear and see if they are important enough to reduce the performance of the system.

Some simplifications were used to analyse the data and obtain valid results. Among them the most important:

- Examining the distribution of HTML block size, it seems that most objects (95 %) are inside the first ten buckets. This means that 95 % of HTML objects have a size smaller than 16 Kbytes. So our test will concentrate on these type of objects.

-It was observed an strong dependency in the relationship block size and READ, COMPRESSION and DECOMPRESSION times. Several interpolations and statistical analysis were performed to obtain the results shown in Figure 5 where the delay times can be calculated in function of the block size.

Figure 5

-The availability of an object locally is always better if no compression is performed. However the system tested was a Sun UltraEnterprise II with a very fast SCSI disk that gives the best performance in the market nowadays. Using other architectures with less disk access performance will cause that the compression could make that compressed objects become available locally before non-compressed ones. A better compression ratio will also improve the effect of the compression.

-While Decompression Times and Read Times remain in comparable values, Compression Times is one magnitude order bigger. In fact if no pre-compression is applied, Read Time and Decompression Time is negligible compared with Compression Times.

Now that all the variables are analysed and set only remains the link that the link is going to cause on each case. Three situations are proposed and compared for each link:

-Precompression in advance.
-Compression before entering the link.
-Plain transmission. No compression or decompression is performed.

Several graphics are provided with different link bandwidths, this will help illustrate when compression is useful and even what bandwidths are improved using compression.

The idea is representing four types of low latency links:

Low Bandwidth link -> 0,1 Kbytes/s
Normal Bandwidth link in Internet -> 1 Kbyte/s
Fast Bandwidth link in Internet or close LANs -> 100 Kbytes/s

Fast links with heavy loads like LANS with Ethernet and a lot of traffic -> 1 Mbyte/s

Very Fast link used in Ethernet networks with few traffic for LANS -> 10 Mbytes/s

Of course there are slower links than 0,1 Kbytes/s and faster links than the speed provided by Ethernet but the range of links selected is meant to cover two different situations:

The three slower links will cover most Internet connections and in general any non-local connection.

The fourth and the fifth ones are meant to cover local connections.

Analysing the four graphs the difference stated above appears more evident. The three slower links have an analogous behaviour:

Figure 6

Figure 7

Figure 8

Pre-compressed and Non-Precompressed architectures have similar performance while Non-compressed traffic (PLAIN) gives about twice the time needed in the other cases. This is just because Compression Times are negligible compared to Transfer Times.

Figure 9

In the fourth link, the behaviour changes dramatically, in this case:

Transfer Time has become comparable to the accumulated delays due to Read, Compress and Decompress processes. That causes the three studied situations to give similar performances and results. The best performance is achieved by pre-compressed link but it is comparable to the one achieved in the other cases.

Figure 10

In the fifth link, the behaviour still experiments more changes, in this case:

Transfer Time has become negligible compared to Compression Time while being comparable to Decompress Time, this causes that PLAIN and Pre-compressed architectures behave in a very similar way while Non-precompressed is clearly outperformed by the others.

FUTURE WORK

The main conclusions of this work are that compression can become a very nice feature in cache architectures if applied selectively to several content types. It has been proved that html files are going to be the target of this feature.

10^th of February, W3C (World Wide Web Consortium) [W3C] proposed XML (Extensible Markup Language) as a recommendation to substitute HTML pages and provide further services that will enhance the possibilities of electronic commerce and services around Web. As XML is going to substitute HTML it will be very interesting to analyse the possibilities of applying compression to XML while establishing some design parameters for future applications. XML is going to provide new features in Markup like meta-data, meta-information, document type definition (DTD), WIDL (Web Interface Definition Languge), XSL (Extensible Sylesheet Language), Namespaces, Xlink and RDF (Resource Description Framework) .... Many of these features can be compressed but sometimes it will be necessary to be selective. Meta-data may allow impressive improvements in search engines, intelligent agents and indexation procedures. So compression will have to be selective to compress only the data not the meta-data.

For more information about these standards check http://www.xml.com, http://www.microsoft.com/xml, http://www.w3c.org and http://www.sgml.com .

REFERENCES

[MARKUS] Markus Franz Xaver Johannes Oberhumer, "LZOP 1.03", http://wildsau.idv.uni-linz.ac.at/mfx/lzo.html

[W3C] 10^th February 1998, World Wide Web Consortium http://www.w3c.org