Professional Documents
Culture Documents
Timothy J. McLaughlin
Department of Computer Science and Engineering
Lehigh University
19 Memorial Drive West
Bethlehem, PA 18015
tjm9@cse.lehigh.edu
GET / HTTP/1.0
6. Browser Support for Compression Accept-Encoding: gzip
Figure 3 – Benchmarking results for the retrieval of the Yahoo HTML file from the Apache Server.
Figure 4 – Benchmarking results for the retrieval of the AOL HTML file from the Apache Server.
Figure 5 – Benchmarking results for the retrieval of the eBay HTML file from the Apache Server.
After the saturation point the numbers especially when compared to the speed of
diverge slightly, as is noticeable in the graphs. today’s average web server.
What this means is that the server was able to
serve almost the same number of requests per Web Site Uncompressed Compressed
second for both compressed and uncompressed Google 3.2 10.2
Yahoo 3.3 27.5
documents. AOL 3.4 34.7
The Google test case shows it is eBay 3.4 51.4
beneficial to impose a limit on the minimum file
size necessary to compress a document. Both Table 3 – Average response time (in milliseconds) for the
mod_gzip and IIS allow the site administrator to Apache server to respond to requests for compressed and
set a lower and upper bound on the size of uncompressed static documents.
compressible resources. Thus if the size of a
resource falls outside of these bounds it will be
11.2.2 IIS Performance Benchmark
sent uncompressed.
For these tests all such bounds were
We attempted to repeat the same tests as
disabled, which caused all resources to be
above using the IIS server. However, our test
compressed regardless of their size.
had to be slightly altered since, unlike mod_gzip
When calculating results we will only
and Apache, IIS does not compress static
look at those cases where the demanded number
documents on the fly. So, to overcome this we
of requests per second is less than or equal to the
simply changed the extension of all of the .html
saturation point. Not surprisingly, compression
files to .asp. Active Server Pages (ASP) are
greatly reduced the network bandwidth required
generated dynamically hence IIS will not cache
for server replies. The factor by which network
them.
bandwidth was reduced roughly corresponds to
Figures 6 through 9 represent graphs of
the compression ratio of the document.
some of the results from each of the respective
test cases. Note from the graphs that, like with
Web Site Uncompressed Compressed Apache, the actual request rate and the average
Google 215 105
Yahoo 36 33 reply rate are identical for the compressed and
AOL 27 25 uncompressed format up until the saturation
EBay 16 15 point. Note also that the average response times
present an interesting value to examine. Recall
Table 2 – Estimated saturation points for the Apache web that with Apache the average reply time was
server based on repeated client requests for the indicated significantly greater when serving compressed
document
content. On the other hand, in IIS, the average
Next we will see the performance response time when serving compressed
effects that on-the-fly compression imposed on dynamic content is the same, and sometimes
the server. To do so we will compare the even a few milliseconds less, than when serving
server’s average response time in serving the uncompressed content. At first we thought this
compressed and uncompressed document. The was happening because the content was
findings are summarized in Table 3. The results somehow being cached even though the IIS
are not particularly surprising. We can see that documentation states that dynamic content is
the size of a static document does not affect never cached [7], so we spent hours searching for
response time when it is requested in an every possible compression and cache setting but
uncompressed form. In the case of to no avail. Finally, we stumbled across what we
compression, however, we can see that as the file believe to be the answer, which is the use of
size of the resource increases so too does the chunked transfer coding. By default IIS does not
average response time. We would certainly chunk the response for an uncompressed
expect to see such results because it takes a document that is dynamically generated via ASP.
slightly longer time to compress larger Figure 10 shows the HTTP response header that
documents. Keep in mind that the time to was generated from the IIS server based on a
compress a document will likely be far smaller client request for an uncompressed ASP
for a faster, more powerful computer. The resource. In this case, IIS generates the entire
machine running as the web server for these tests page dynamically before returning it to the
has a modest amount of computing power, client.
Figure 6 – Benchmarking results for the retrieval of the Google HTML file from the IIS Server.
Figure 7 – Benchmarking results for the retrieval of the Yahoo HTML file from the IIS Server.
Figure 8 – Benchmarking results for the retrieval of the AOL HTML file from the IIS Server.
Figure 9 – Benchmarking results for the retrieval of the eBay HTML file from the IIS Server.
However, as we can see in Figure 11, compressing dynamic content provides
when a client requests an ASP file in compressed significant performance benefits.
form, IIS appears to send the compressed content
to the client in chunks. Thus, the server can 12. Summary / Suggestions
immediately compress and send chunks of data
as they are dynamically generated without So, should a web server use HTTP
having to wait for the entire document to be compression? Well, that’s not such an easy
generated before performing this process [2]. question to answer. There are a number of
Such a process appears to significantly reduce things that must first be considered. For
response time latency. In this way IIS is able to instance, if the server generates a large amount
achieve average response times that are identical of dynamic content one must consider whether
to the response times for uncompressed content. the server can handle the additional processing
costs of on-the-fly compression while still
maintaining acceptable performance. Thus it
HTTP/1.1 200 OK must be determined whether the price of a few
Server: Microsoft-IIS/5.0
Date: Tue, 11 Dec 2001 18:01:09 GMT extra CPU cycles per request is an acceptable
Connection: close trade-off for reduced network bandwidth. Also,
Content-Length: 13506 compression currently comes at the price of
Content-Type: text/html
Set-Cookie:
cacheability, as we saw in section 9.
ASPSESSIONIDGGQQQJHK=EJKABPBDEDGHBPLPLMDP Much Internet content is already
EAHA; path=/ compressed, such as GIF and JPEG images and
Cache-control: private streaming audio and video. However, a large
portion of the Internet is text based and is
Figure 10 – HTTP response header from an IIS Server after a
request for an uncompressed .asp resource
currently being transferred uncompressed. As
we have seen, HTTP compression is an
underutilized feature on the web today. This
HTTP/1.1 200 OK despite the fact that support for compression is
Server: Microsoft-IIS/5.0 built into most modern web browsers and
Date: Tue, 11 Dec 2001 18:01:01 GMT
Connection: close servers. Furthermore, the fact that most
Content-Type: text/html browsers running in the Windows environment
Set-Cookie: perform streaming decompression of gzipped
ASPSESSIONIDGGQQQJHK=DJKABPBDPEAMPJHEBNIH
CBHB; path=/
content is beneficial because a client receiving a
Content-Encoding: gzip compressed HTML file can decompress the file
Transfer-Encoding: chunked as new packets of data arrive rather than having
Expires: Wed, 01 Jan 1997 12:00:00 GMT to wait for the entire object to be retrieved. Our
Cache-Control: private, max-age=86400
Vary: Accept-Encoding tests indicated that 27% byte reductions are
possible for the average web site, proving the
Figure 11 – HTTP response header from an IIS Server after a practicality of HTTP compression. However, in
request for a compressed .asp resource order for HTTP compression to gain popularity a
few things need to occur.
The graphs show that the lines for the First, the design of a new patent free
average response times follow nearly identical algorithm that is tailored specifically towards
paths for the Google, Yahoo! and AOL test case, compressing web documents, such as HTML and
though there is a slight divergence in the AOL CSS, could be helpful. After all, gzip and deflate
test as you near the saturation point. In the eBay are simply general purpose compression schemes
test, however, the server achieves must quicker and do not take into account the content type of
average response times. Again, this can be the input stream. Therefore, an algorithm that,
explained by the server’s use of chunked for instance, has a predefined library of common
transfers. Looking at the graphs we can see that HTML tags could provide a much higher
for the Google, Yahoo! and AOL test cases, the compression ratio than gzip or deflate.
saturation point is roughly equivalent regardless Secondly, we believe expanded support
of whether the content is served in a compressed for compressed transfer coding is essential.
form or not. Currently, support for this feature is scarce in
Based on these results we conclude that most browsers, proxies and servers. Based on
the use of chunked transfer coding for the browser test in Section 6 we can see that as
of Netscape 6.2 and Internet Explorer 6.0,
neither browser fully supports transfer coding. [4] T. Berners-Lee, R. Fielding, and H. Frystyk.
Opera 5 was the only browser tested that Hypertext Transfer Protocol - HTTP/1.0.
indicated its ability to handle transfer coding by RFC 1945, HTTP Working Group, May
issuing a TE header field along with each HTTP 1996. http://www.ietf.org/rfc/rfc1945.txt
request. As far as proxies are concerned, Squid
appears only to support compressed content [5] R. Fielding, J. Gettys, J. Mogul, H. Frystyk,
coding, but not transfer coding, in its current L. Masinter, P. Leach, and T. Berners-Lee.
version. According to the Squid development Hypertext Transfer Protocol -- HTTP/1.1.
project web site [44] a beta version of a patch RFC 2616, HTTP Working Group, June
was developed to extend Squid to handle transfer 1999. http://www.ietf.org/rfc/rfc2616.txt
coding. However, the patch has not been
updated recently and the status of this particular [6] H.F. Nielsen, J. Gettys, A. Baird-Smith, E.
project is listed as idle and in need of developers. Prud'hommeaux, H. W. Lie, and C. Lilley.
Also, in our research we found no evidence of Network Performance Effects of HTTP/1.1,
support for compressed transfer coding in either CSS1, and PNG. In Proceedings of ACM
Apache or IIS. SIGCOMM'97 Conference, September
The most important thing in regards to 1997.
HTTP compression, in our opinion, is the need http://www.w3.org/Protocols/HTTP/Perform
for expanded proxy support. As of now ance/Pipeline.html
compression comes at the price of uncacheability
in most instances. As we saw, outside of the [7] Microsoft Corporation. Microsoft Windows
latest version of Squid, little proxy support exists 2000 Server Documentation.
for the Vary header. So, even though a given http://www.microsoft.com/windows2000/en/
resource may be compressible by a large factor, server/iis/. Feb 28, 2000.
this effectiveness is negated if the server has to
constantly retransmit this compressed document [8] Mozilla. performance: HTTP Compression.
to clients who should have otherwise been http://www.mozilla.org/projects/apache/gzip
served by a proxy cache. /. Sept 15, 1998.
Until these issues can be resolved
HTTP compression will likely continue to be [9] Remote Communications, Inc. RCI’s
overlooked as a way to reduce user perceived mod_gzip FAQ.
latency and improve Web performance. http://www.remotecommunications.com/apa
che/mod_gzip/mod_gzip_faq.htm. 2001.
Acknowledgements
[10] BrowserSpy. The BrowserSpy program.
Thanks are due to Brian D. Davison for http://www.suvi.org/projects/browserspy.
valuable insight and suggestions. html. 2002.
[19] eBay. The eBay Home Page. [31] Microsoft Corp. IIS: Enabling HTTP
http://www.ebay.com/. 2001. Compression Returns Content with
January 1, 1997 Expiration Date.
[20] T.J. Midgley. Autobench. http://support.microsoft.com/default.aspx?
http://www.xenoclast.org/autobench/. Jun scid=kb;EN-US;q272596. June 13, 2001.
27, 2001.
[34] Microsoft Corp. About Capacity Planning.
[21] J. Laffey. [Mod_gzip] "Vary" Header. Post http://iishelp.web.cern.ch/IISHelp/iis/htm/
to the [Mod_gzip] message board. core/iiprftn.htm. Feb 28, 2000.
http://lists.over.net/pipermail/mod_gzip/2
001-April/001806.html. April 12, 2001. [35] Packeteer, Inc. Internet Application
Acceleration using Packeteer’s AppCelera
[22] I. Holsman. [PATCH] Add mod_gz to ICX.
httpd-2.0. Post to the [PATCH] message http://www.packeteer.com/PDF_files/app
board. http://www.mail- celera/icx/icx55_paper.pdf. 2001.
archive.com/dev@httpd.apache.org/msg0
0748.html. Sept 1, 2001. [36] Faqs.org. Compression FAQ.
http://www.faqs.org/faqs/compression-
[23] Squid Web Proxy Cache. faq/. Nov 11, 2001.
http://www.squid-cache.org/. Oct 12,
2001. [37] Autosophy. The V.42bis Compression
Standard and Beyond.
[24] S. Young. Making your website super fast- http://www.autosophy.com/v42bisintro.ht
loading. http://www.msxnet.org/fast- m. 2001.
website.html. 2001.
[38] P. Peterlin. Why Compression? Why Gzip?
[25] GNU. The gzip Home Page. http://sizif.mf.uni-lj.si/gzip.html. Nov 18,
http://www.gzip.org/. Nov 5, 2001. 1997.