Re: compression settings in IIS 6
From: Abe Klagsbrun [MSFT] (abekl_at_online.microsoft.com)
Date: 03/08/04
- Next message: Wade A. Hilmo [MS]: "Re: Changing browser Url via ISAPI Filter"
- Previous message: Brad Aisa: "Changing browser Url via ISAPI Filter"
- In reply to: jaymack: "compression settings in IIS 6"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 8 Mar 2004 12:58:35 -0800
Hi Jay,
Here is an excerpt from the updated IIS 6 Resource Guide (Also called the
IIS 6.0 Technical Reference), which will be going live on TechNet sometime
during March.
-------------------------
Using HTTP Compression for Faster Downloads
If your Web sites use large amounts of bandwidth or if you want to use
bandwidth more effectively, consider enabling HTTP compression, which
provides faster transmission times between IIS and compression-enabled
browsers regardless of whether your content is served from local storage
or a UNC resource. If your network bandwidth is restricted, HTTP compression
can be beneficial unless your processor usage is already very high.
IIS provides the following compression options:
- Static files only.
- Dynamic application responses only.
- Both static files and dynamic application responses.
Dynamic processing can affect CPU resources because IIS does not cache
compressed versions of dynamic output. If compression is enabled for dynamic
responses and IIS receives a request for a file that contains dynamic
content,
the response that IIS sends is compressed every time it is requested.
Because
dynamic compression consumes considerable CPU time and memory resources, use
it only on servers that have slow network connections but CPU time to spare.
Compressed static responses can be cached and therefore do not affect CPU
resources like dynamic responses do.
How HTTP Compression Works
When IIS receives a request, it checks whether the browser that sent the
request is compression-enabled. (Recent versions of Microsoft® Internet
Explorer and most other browsers typically send the following header if
they are compression-enabled: Accept-Encoding: gzip, deflate.) IIS then
determines whether the request is for a static file or for dynamic content.
If the content of the file is static, IIS checks whether the file has
previously been requested and is already stored in a compressed format in
the temporary compression directory. If a compressed version of the
requested
file is not found, IIS sends an uncompressed version of the requested file
to the client browser while a background thread compresses the requested
file.
The newly compressed file is then stored in the compression directory, and
subsequent requests for that file are serviced directly from the compression
directory. In other words, an uncompressed version of the file is returned
to the client unless a compressed version of the file already exists in the
compression directory.
If the file contains dynamic content, IIS compresses the response as it is
generated and sends the compressed response to the browser. No copy of the
file is cached by the Web server.
The performance cost of compressing a static file is modest and is typically
incurred only once, because the file is then stored in the temporary
compression directory. The cost of compressing dynamically generated files
is
somewhat higher because the files are not cached and must be regenerated
with
each request. The cost of expanding the file at the browser is minimal.
Compressed files download faster, which makes them particularly beneficial
to the performance of any browser that uses a network connection with
restricted bandwidth (a modem connection, for example).
When you enable HTTP compression, compressed files are given a default
expiration date of Jan. 1, 1997. This expiration date prevents proxy
servers from serving cached copies of compressed files to browsers that
are not compression-enabled. This expiration date also forces browsers
to return to the server for a fresh copy of the file when the user makes
a new request instead of displaying a cached copy of the file. When you
enable HTTP compression, the default settings for the HcExpiresHeader,
HcCacheControlHeader, and HcSendCacheHeaders metabase properties ensure
that older clients and proxy servers do not attempt to cache compressed
files. Before you change these settings, see "Metabase Property Reference"
in IIS 6.0 Help for information about these and related metabase properties.
--------------------------
"jaymack" <anonymous@discussions.microsoft.com> wrote in message
news:4DF493BA-6B5D-4100-826B-99460AF95CDF@microsoft.com...
>i currently have compression for static files enabled and I see about 25
>htm files in the compression directory. when i turn on compression for app
>files i see about 5-10 more htm files show up. What exactly is taking place
>when application compression is turned on? is there compression on the fly
>taking place if the browser supports it? will compression of dynamic files
>take place at all? the site is 90% dynamic with asp/aspx will compression
>help at all? I guess a granular detail of what the application compression
>setting does would be helplful. thanks
>
> jay mack
- Next message: Wade A. Hilmo [MS]: "Re: Changing browser Url via ISAPI Filter"
- Previous message: Brad Aisa: "Changing browser Url via ISAPI Filter"
- In reply to: jaymack: "compression settings in IIS 6"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
