You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@trafficserver.apache.org by ig...@apache.org on 2011/05/18 22:55:13 UTC
svn commit: r1124427 - in
/trafficserver/site/branches/ats-cms/content/docs/trunk/admin:
configuration-files/records.config.en.mdtext
getting-started/index.en.mdtext http-proxy-caching/index.en.mdtext
index.en.mdtext
Author: igalic
Date: Wed May 18 20:55:12 2011
New Revision: 1124427
URL: http://svn.apache.org/viewvc?rev=1124427&view=rev
Log:
Second pass of editing: This time around I'm actually reading, and trying to understand the *content*
If this commit message lacks esprit and wit, it's due to exhaustion. Please observe that the diff is ~50% of the files length...
Modified:
trafficserver/site/branches/ats-cms/content/docs/trunk/admin/configuration-files/records.config.en.mdtext
trafficserver/site/branches/ats-cms/content/docs/trunk/admin/getting-started/index.en.mdtext
trafficserver/site/branches/ats-cms/content/docs/trunk/admin/http-proxy-caching/index.en.mdtext
trafficserver/site/branches/ats-cms/content/docs/trunk/admin/index.en.mdtext
Modified: trafficserver/site/branches/ats-cms/content/docs/trunk/admin/configuration-files/records.config.en.mdtext
URL: http://svn.apache.org/viewvc/trafficserver/site/branches/ats-cms/content/docs/trunk/admin/configuration-files/records.config.en.mdtext?rev=1124427&r1=1124426&r2=1124427&view=diff
==============================================================================
--- trafficserver/site/branches/ats-cms/content/docs/trunk/admin/configuration-files/records.config.en.mdtext (original)
+++ trafficserver/site/branches/ats-cms/content/docs/trunk/admin/configuration-files/records.config.en.mdtext Wed May 18 20:55:12 2011
@@ -830,8 +830,11 @@ the `records.config` file.
*`proxy.config.http.cache.cache_urls_that_look_dynamic`* {#proxy.config.http.cache.cache_urls_that_look_dynamic}
: `INT`
-: Default: `0`
-: Enables (`1`) or disables (`0`) caching of URLs that look dynamic.
+: Default: `1`
+: Enables (`1`) or disables (`0`) caching of URLs that look dynamic, i.e.: URLs that end in **`.asp`** or
+ contain a question mark (**`?`**), a semicolon (**`;`**), or **`cgi`**.
+
+ For a full list, please refer to [HttpTransact::url_looks_dynamic](/link/to/doxygen)
*`proxy.config.http.cache.enable_default_vary_headers`* {#proxy.config.http.cache.enable_default_vary_headers}
: `INT`
@@ -975,6 +978,11 @@ the `records.config` file.
: When enabled (`1`), Traffic Server ignores any
`Cache-Control: max-age` headers from the client.
+*`proxy.config.cache.permit.pinning`* {#proxy.config.cache.permit.pinning}
+: `INT`
+: Default: `0`
+: When enabled (`1`), Traffic Server will keep certain HTTP objects in the cache for a certain time as
+ specified in [`cache.config`](cache.config).
### Heuristic Expiration ### {#HeuristicExpiration}
@@ -1017,7 +1025,7 @@ the `records.config` file.
: Default: `NULL`
: The header on which Traffic Server varies for text documents.
- For example: if you specify `user-agent`, then Traffic Server
+ For example: if you specify `User-agent`, then Traffic Server
caches all the different user-agent versions of documents it
encounters.
Modified: trafficserver/site/branches/ats-cms/content/docs/trunk/admin/getting-started/index.en.mdtext
URL: http://svn.apache.org/viewvc/trafficserver/site/branches/ats-cms/content/docs/trunk/admin/getting-started/index.en.mdtext?rev=1124427&r1=1124426&r2=1124427&view=diff
==============================================================================
--- trafficserver/site/branches/ats-cms/content/docs/trunk/admin/getting-started/index.en.mdtext (original)
+++ trafficserver/site/branches/ats-cms/content/docs/trunk/admin/getting-started/index.en.mdtext Wed May 18 20:55:12 2011
@@ -26,26 +26,20 @@ for [build instructions](https://cwiki.a
After you have installed Traffic Server on your system, you can do any of the
following:
-* [Start Traffic Server](#StartTS)
-* [Start Traffic Line](#StartTrafficLine)
-* [Start Traffic Shell](#StartTrafficShell)
-* [Stop Traffic Server](#StopTS)
+[TOC]
-## Start Traffic Server ## {#StartTS}
+# Start Traffic Server # {#StartTS}
To start Traffic Server manually, issue the `trafficserver` command, passing
in the attribute `start`. This command starts all the processes that work together
to process Traffic Server requests as well as manage, control, and monitor
the health of the Traffic Server system.
-##### To run the `trafficserver start` command: ##### {#runTSstartcommand}
-
-1. Log on to the Traffic Server node as the Traffic Server administrator and navigate to the Traffic Server `bin` directory.
-2. Enter the following command:
+To run the `trafficserver start` command, e.g.:
./trafficserver start
-## Start Traffic Line ## {#StartTrafficLine}
+# Start Traffic Line # {#StartTrafficLine}
Traffic Line provides a quick way of viewing Traffic Server statistics and
configuring the Traffic Server system via command-line interface. To execute
@@ -59,7 +53,7 @@ For a list of `traffic_line` commands, e
./traffic_line -h
-## Start Traffic Shell ## {#StartTrafficShell}
+# Start Traffic Shell # {#StartTrafficShell}
Traffic Shell is a command-line tool that enables you to monitor and configure
Traffic Server; it can be used instead of Traffic Line. Traffic Server provides
@@ -73,7 +67,7 @@ commands, and how to obtain documentatio
man traffic_shell
-## Stop Traffic Server ## {#StopTS}
+# Stop Traffic Server # {#StopTS}
To stop Traffic Server, always use the `trafficserver` command, passing in
the attribute `stop`. This command stops all the Traffic Server processes (`traffic_manager`,
Modified: trafficserver/site/branches/ats-cms/content/docs/trunk/admin/http-proxy-caching/index.en.mdtext
URL: http://svn.apache.org/viewvc/trafficserver/site/branches/ats-cms/content/docs/trunk/admin/http-proxy-caching/index.en.mdtext?rev=1124427&r1=1124426&r2=1124427&view=diff
==============================================================================
--- trafficserver/site/branches/ats-cms/content/docs/trunk/admin/http-proxy-caching/index.en.mdtext (original)
+++ trafficserver/site/branches/ats-cms/content/docs/trunk/admin/http-proxy-caching/index.en.mdtext Wed May 18 20:55:12 2011
@@ -26,47 +26,39 @@ other tasks.
This chapter discusses the following topics:
-* [Understanding HTTP Web Proxy Caching](#UnderstandingHTTPWebProxyCaching)
-* [Ensuring Cached Object Freshness](#EnsuringCachedObjectFreshness)
-* [Scheduling Updates to Local Cache Content](#SchedulingUpdatesToLocalCacheContent)
-* [Pushing Content into the Cache](#PushingContentIntoCache)
-* [Pinning Content in the Cache](#PinningContentInCache)
-* [To Cache or Not to Cache?](#ToCacheOrNotToCache)
-* [Forcing Object Caching](#ForcingObjectCaching)
-* [Caching HTTP Alternates](#CachingHTTPAlternates)
-* [Using Congestion Control](#UsingCongestionControl)
+[TOC]
-## Understanding HTTP Web Proxy Caching ## {#UnderstandingHTTPWebProxyCaching}
+# Understanding HTTP Web Proxy Caching # {#UnderstandingHTTPWebProxyCaching}
Internet users direct their requests to web servers all over the Internet.
A caching server must act as a **web proxy server** so it can serve those requests.
After a web proxy server receives requests for web objects, it either serves
the requests or forwards them to the **origin server** (the web server that
contains the original copy of the requested information). The Traffic Server
-proxy supports **explicit proxy caching**, in which the userâs client software
+proxy supports **explicit proxy caching**, in which the user's client software
must be configured to send requests directly to the Traffic Server proxy. The
-following overview illustrates how Traffic Server serves a user request.
+following overview illustrates how Traffic Server serves a request.
-1. Traffic Server receives a user request for a web object.
+1. Traffic Server receives a client request for a web object.
1. Using the object address, Traffic Server tries to locate the requested
object in its object database (**cache**).
1. If the object is in the cache, then Traffic Server checks to see
if the object is fresh enough to serve. If it is fresh, then Traffic Server
-serves it to the user as a **cache hit** (see the figure below).
+serves it to the client as a **cache hit** (see the figure below).
1. If the data in the cache is stale, then Traffic Server connects
to the origin server and checks if the object is still fresh (a **revalidation**).
-If it is, then Traffic Server immediately sends the cached copy to the user.
+If it is, then Traffic Server immediately sends the cached copy to the client.
1. If the object is not in the cache (a **cache miss**) or if the server
indicates the cached copy is no longer valid, then Traffic Server obtains the
object from the origin server. The object is then simultaneously streamed to
-the user and the Traffic Server local cache (see the figure below). Subsequent
+the client and the Traffic Server local cache (see the figure below). Subsequent
requests for the object can be served faster because the object is retrieved
directly from cache.
@@ -79,7 +71,7 @@ serves correct HTTP alternates, and trea
not be cached. The following sections discuss these issues in greater detail.
-## Ensuring Cached Object Freshness ## {#EnsuringCachedObjectFreshness}
+# Ensuring Cached Object Freshness # {#EnsuringCachedObjectFreshness}
When Traffic Server receives a request for a web object, it first tries to
locate the requested object in its cache. If the object is in cache, then Traffic
@@ -128,10 +120,10 @@ Traffic Server determines whether an HTT
Revalidate rules apply freshness limits to specific HTTP objects. You can set freshness
limits for objects originating from particular domains or IP addresses, objects with URLs
that contain specified regular expressions, objects requested by particular clients,
- and so on (refer to [cache.config](files.htm#cache.config)).
+ and so on (refer to [`cache.config`](../configuration-files/cache.config)).
-### Modifying the Aging Factor for Freshness Computations ### {#ModifyingAgingFactorFreshnessComputations}
+## Modifying Aging Factor for Freshness Computations ## {#ModifyingAgingFactorFreshnessComputations}
If an object does not contain any expiration information, then Traffic Server
can estimate its freshness from the `Last-Modified` and `Date` headers. By
@@ -139,26 +131,26 @@ default, Traffic Server stores an object
it last changed. You can increase or reduce the percentage according to your
needs.
-##### To modify the aging factor for freshness computations: ##### {#modifyagingfactorfreshnesscomputations}
+To modify the aging factor for freshness computations
-1. In [`records.config`](../configuration-files/records.config)
-2. edit [_`proxy.config.http.cache.heuristic_lm_factor`_](../configuration-files/records.config#proxy.config.http.cache.heuristic_lm_factor)
+1. Edit the following variables in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.http.cache.heuristic_lm_factor`_](../configuration-files/records.config#proxy.config.http.cache.heuristic_lm_factor)
3. Run the `traffic_line -x` command to apply the configuration changes.
-### Setting an Absolute Freshness Limit ### {#SettinganAbsoluteFreshnessLimit}
+## Setting absolute Freshness Limits ## {#SettinganAbsoluteFreshnessLimit}
Some objects do not have `Expires` headers or do not have both `Last-Modified`
and `Date` headers. To control how long these objects are considered fresh
in the cache, specify an **absolute freshness limit**.
-##### To specify an absolute freshness limit: ##### {#specifyanabsolutefreshnesslimit}
+To specify an absolute freshness limit
-1. In [`records.config`](../configuration-files/records.config)
-2. edit [_`proxy.config.http.cache.heuristic_min_lifetime`_](../configuration-files/records.config#proxy.config.http.cache.heuristic_min_lifetime)
-2. edit [_`proxy.config.http.cache.heuristic_max_lifetime`_](../configuration-files/records.config#proxy.config.http.cache.heuristic_max_lifetime)
+1. Edit the following variables in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.http.cache.heuristic_min_lifetime`_](../configuration-files/records.config#proxy.config.http.cache.heuristic_min_lifetime)
+ * [_`proxy.config.http.cache.heuristic_max_lifetime`_](../configuration-files/records.config#proxy.config.http.cache.heuristic_max_lifetime)
3. Run the `traffic_line -x` command to apply the configuration changes.
-### Specifying Header Requirements ### {#SpecifyingHeaderRequirements}
+## Specifying Header Requirements ## {#SpecifyingHeaderRequirements}
To further ensure freshness of the objects in the cache, configure Traffic
Server to cache only objects with specific headers. By default, Traffic Server
@@ -169,13 +161,13 @@ the cache hit rate will be noticeably re
have explicit expiration information).
-##### To configure Traffic Server to cache objects with specific headers: ##### {#configureTScacheobjectswithspecificheaders}
+To configure Traffic Server to cache objects with specific headers
-1. In [`records.config`](../configuration-files/records.config)
-2. edit [_`proxy.config.http.cache.required_headers`_](../configuration-files/records.config#proxy.config.http.cache.required_headers)
+1. Edit the following variable in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.http.cache.required_headers`_](../configuration-files/records.config#proxy.config.http.cache.required_headers)
3. Run the `traffic_line -x` command to apply the configuration changes.
-### Cache-Control Headers ### {#Cache-ControlHeaders}
+## Cache-Control Headers ## {#Cache-ControlHeaders}
Even though an object might be fresh in the cache, clients or servers often
impose their own constraints that preclude retrieval of the object from the
@@ -189,28 +181,27 @@ headers that appear in both client reque
not to serve any objects directly from the cache; therefore, Traffic Server will
always obtain the object from the origin server. You can configure Traffic Server
to ignore client `no-cache` headers - refer to
- [Configuring Traffic Server to Ignore Client no-cache Headers](#NoCacheHeaders) for more information.
+ [Configuring Traffic Server to Ignore Client no-cache Headers](#ConfiguringTSIgnoreClientnocacheHeaders) for more information.
* The `max-age` header, sent by servers, is compared to the object age.
If the age is less than `max-age`, then the object is fresh and can be served.
* The `min-fresh` header, sent by clients, is an **acceptable freshness tolerance**.
This means that the client wants the object to be at least this fresh.
- If a cached object does not remain fresh at least this long in the future, then it is revalidated.
+ Unless a cached object remains fresh at least this long in the future, it is revalidated.
* The `max-stale` header, sent by clients, permits Traffic Server to serve stale
objects provided they are not too old. Some browsers might be willing to take
slightly stale objects in exchange for improved performance, especially during
periods of poor Internet availability.
-Traffic Server applies `Cache-Control` servability criteria after HTTP freshness
+Traffic Server applies `Cache-Control` servability criteria ***after*** HTTP freshness
criteria. For example, an object might be considered fresh but will not be
served if its age is greater than its `max-age`.
-### Revalidating HTTP Objects ### {#RevalidatingHTTPObjects}
-
+## Revalidating HTTP Objects ## {#RevalidatingHTTPObjects}
When a client requests an HTTP object that is stale in the cache, Traffic Server
revalidates the object. A **revalidation** is a query to the origin server
@@ -221,7 +212,7 @@ the following:
limit and serves the object.
* If a new copy of the object is available, then Traffic Server caches the
- new object (thereby replacing the stale copy) and simultaneously serves the object to the user.
+ new object (thereby replacing the stale copy) and simultaneously serves the object to the client.
* If the object no longer exists on the origin server, then Traffic Server
does not serve the cached copy.
@@ -242,32 +233,32 @@ how Traffic Server evaluates freshness b
To configure how Traffic Server revalidates objects in the cache, you can set
specific revalidation rules in [`cache.config`](../configuration-files/records.config).
-##### To configure revalidation options: ##### {#configurerevalidationoptions}
+To configure revalidation options
-1. In [`records.config`](../configuration-files/records.config)
-2. edit [_`proxy.config.http.cache.when_to_revalidate`_](../configuration-files/records.config#proxy.config.http.cache.when_to_revalidate)
+1. Edit the following variable in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.http.cache.when_to_revalidate`_](../configuration-files/records.config#proxy.config.http.cache.when_to_revalidate)
3. Run the `traffic_line -x` command to apply the configuration changes.
-## Scheduling Updates to Local Cache Content ## {#SchedulingUpdatesLocalCacheContent}
+# Scheduling Updates to Local Cache Content # {#SchedulingUpdatesLocalCacheContent}
To further increase performance and to ensure that HTTP objects are fresh in
the cache, you can use the **Scheduled Update** option. This configures Traffic
Server to load specific objects into the cache at scheduled times. You might
-find this especially beneficial when using Traffic Server as a reverse proxy
-so you can preload content you anticipate will be in demand.
+find this especially beneficial in a reverse proxy setup, where you can
+*preload* content you anticipate will be in demand.
To use the Scheduled Update option, you must perform the following tasks.
-* Specify the list of URLs that contain the objects you want to schedule
- for update, the time the update should take place, and the recursion depth for the URL.
-
+* Specify the list of URLs that contain the objects you want to schedule for update,
+* the time the update should take place,
+* and the recursion depth for the URL.
* Enable the scheduled update option and configure optional retry settings.
Traffic Server uses the information you specify to determine URLs for which
it is responsible. For each URL, Traffic Server derives all recursive URLs
(if applicable) and then generates a unique URL list. Using this list, Traffic
-Server initiates an HTTP `GET` for each unaccessed URL, ensuring that it remains
+Server initiates an HTTP `GET` for each unaccessed URL. It ensures that it remains
within the user-defined limits for HTTP concurrency at any given time. The
system logs the completion of all HTTP `GET` operations so you can monitor
the performance of this feature.
@@ -278,32 +269,31 @@ to occur. You can use this option to tes
(refer to [Forcing an Immediate Update](#ForcingImmediateUpdate)).
-### Configuring the Scheduled Update Option ### {#ConfiguringScheduledUpdateOption}
-
+## Configuring the Scheduled Update Option ## {#ConfiguringScheduledUpdateOption}
-##### To configure the scheduled update option: ##### {#configurescheduledupdateoption}
+To configure the scheduled update option
-1. In [`update.config`](../configuration-files/update.config) enter a line in the file for each URL you want to update.
-1. In [`records.config`](../configuration-files/records.config)
-2. edit [_`proxy.config.update.enabled`_](../configuration-files/records.config#proxy.config.http.update.enabled)
-2. edit [_`proxy.config.update.retry_count`_](../configuration-files/records.config#proxy.config.http.update.retry_count)
-2. edit [_`proxy.config.update.retry_interval`_](../configuration-files/records.config#proxy.config.http.update.retry_interval)
-2. edit [_`proxy.config.update.concurrent_updates`_](../configuration-files/records.config#proxy.config.http.update.concurrent_updates)
+1. Edit [`update.config`](../configuration-files/update.config) to enter a line in the file for each URL you want to update.
+1. Edit the following variables in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.update.enabled`_](../configuration-files/records.config#proxy.config.http.update.enabled)
+ * [_`proxy.config.update.retry_count`_](../configuration-files/records.config#proxy.config.http.update.retry_count)
+ * [_`proxy.config.update.retry_interval`_](../configuration-files/records.config#proxy.config.http.update.retry_interval)
+ * [_`proxy.config.update.concurrent_updates`_](../configuration-files/records.config#proxy.config.http.update.concurrent_updates)
3. Run the `traffic_line -x` command to apply the configuration changes.
-### Forcing an Immediate Update ### {#ForcingImmediateUpdate}
+## Forcing an Immediate Update ## {#ForcingImmediateUpdate}
Traffic Server provides a **Force Immediate Update** option that enables you
to immediately verify the URLs listed in the `update.config` file. The Force
Immediate Update option disregards the offset hour and interval set in the
`update.config` file and immediately updates the URLs listed.
-##### To configure the Force Immediate Update option: ##### {#configureForceImmediateUpdateoption}
+To configure the Force Immediate Update option
-1. In [`records.config`](../configuration-files/records.config)
-2. edit [_`proxy.config.update.force`_](../configuration-files/records.config#proxy.config.http.update.force)
-2. Make sure the variable [_`proxy.config.update.enabled`_](../configuration-files/records.config#proxy.config.http.update.enabled) is set to 1.
+1. Edit the following variables in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.update.force`_](../configuration-files/records.config#proxy.config.http.update.force)
+ * Make sure the variable [_`proxy.config.update.enabled`_](../configuration-files/records.config#proxy.config.http.update.enabled) is set to 1.
7. Run the `command traffic_line -x` to apply the configuration changes.
**IMPORTANT:** When you enable the Force Immediate Update option, Traffic Server
@@ -312,21 +302,20 @@ disable the option. To disable the Force
[_`proxy.config.update.force`_](../configuration-files/records.config#proxy.config.http.update.force) to `0` (zero).
-## Pushing Content into the Cache ## {#PushingContentintoCache}
+# Pushing Content into the Cache # {#PushingContentintoCache}
Traffic Server supports the HTTP `PUSH` method of content delivery. Using HTTP
-`PUSH`, you can deliver content directly into the cache without user requests.
+`PUSH`, you can deliver content directly into the cache without client requests.
-### Configuring Traffic Server to Accept PUSH Requests ### {#ConfiguringTSAcceptPUSHRequests}
+## Configuring Traffic Server for PUSH Requests ## {#ConfiguringTSPUSHRequests}
Before you can deliver content into your cache using HTTP `PUSH`, you must
configure Traffic Server to accept `PUSH` requests.
-##### To configure Traffic Server to accept `PUSH` requests: ##### {#configureTSacceptPUSHrequests}
+To configure Traffic Server to accept `PUSH` requests
-1. In [`filter.config`](../configuration-files/filter.config)
-2. Add the following filter rules to the file to ensure that only certain IP addresses can deliver `PUSH` requests to the cache:
+1. Edit [`filter.config`](../configuration-files/filter.config), adding the following filter rules to the file to ensure that only certain IP addresses can deliver `PUSH` requests to the cache:
:::text
domain=. src_ip=ipaddress method=PUSH action=allow
@@ -334,12 +323,12 @@ configure Traffic Server to accept `PUSH
where _`ipaddress`_ is the IP address of the host or range of IP addresses of the hosts from
which Traffic Server accepts `PUSH` requests.
-3. In [`records.config`](../configuration-files/records.config)
-4. edit [_`proxy.config.http.push_method_enabled`_](../configuration-files/records.config#proxy.config.http.push_method_enabled)
+3. Edit the following variable in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.http.push_method_enabled`_](../configuration-files/records.config#proxy.config.http.push_method_enabled)
5. Run the command `traffic_line -x` to apply the configuration changes.
-### Understanding HTTP PUSH ### {#UnderstandingHTTPPUSH}
+## Understanding HTTP PUSH ## {#UnderstandingHTTPPUSH}
`PUSH` uses the HTTP 1.1 message format. The body of a `PUSH` request contains
the response header and response body that you want to place in the cache.
@@ -357,11 +346,11 @@ The following is an example of a `PUSH`
</HTML>
-**IMPORTANT:** Your header must include `Content-length`; `Content-length`
+**IMPORTANT:** Your header must include `Content-length` - `Content-length`
must include both `header` and `body byte count`.
-## Pinning Content in the Cache ## {#PinningContentinCache}
+# Pinning Content in the Cache # {#PinningContentinCache}
The **Cache Pinning Option** configures Traffic Server to keep certain HTTP
objects in the cache for a specified time. You can use this option to ensure
@@ -369,22 +358,20 @@ that the most popular objects are in cac
Server from deleting important objects. Traffic Server observes `Cache-Control`
headers and pins an object in the cache only if it is indeed cacheable.
-##### To set cache pinning rules and enable Cache Pinning: ##### {#setcachepinningrulesenableCachePinning}
+To set cache pinning rules
-1. In [`cache.config`](../configuration-files/cache.config)
-2. Add a rule in the file for each URL you want Traffic Server to pin in the cache, as shown below.
+3. Make sure the following variable in [`records.config`](../configuration-files/records.config) is set
+ * [_`proxy.config.cache.permit.pinning`_](../configuration-files/records.config#proxy.config.cache.permit.pinning)
- url_regex=URL pin-in-cache=12h
- where _`URL`_ is the URL you want Traffic Server to pin in the cache. The time format can be `d` for days,
- `h` for hours (as shown), `m` for minutes, and `s` for seconds. You can also use mixed units:
- for example, `1h15m20s`. You can add secondary specifiers (such as prefix and suffix) to the rule.
+1. Add a rule in [`cache.config`](../configuration-files/cache.config) for each URL you want Traffic Server to pin in the cache. For example:
+
+ :::text
+ url_regex=^https?://(www.)?apache.org/dev/ pin-in-cache=12h
-3. In [`records.config`](../configuration-files/records.config)
-4. edit [_`proxy.config.cache.permit.pinning`_](../configuration-files/records.config#proxy.config.cache.permit.pinning)
8. Run the command `traffic_line -x` to apply the configuration changes.
-## To Cache or Not to Cache? ## {#CacheNotCache}
+# To Cache or Not to Cache? # {#CacheNotCache}
When Traffic Server receives a request for a web object that is not in the
cache, it retrieves the object from the origin server and serves it to the
@@ -392,22 +379,26 @@ client. At the same time, Traffic Server
before storing it in its cache to serve future requests.
-## Caching HTTP Objects ## {#CachingHTTPObjects}
+# Caching HTTP Objects # {#CachingHTTPObjects}
Traffic Server responds to caching directives from clients and origin servers,
as well as directives you specify through configuration options and files.
-### Client Directives ### {#ClientDirectives}
+## Client Directives ## {#ClientDirectives}
-By default, Traffic Server does _not_ cache objects with the following **request**
-**headers**:
+By default, Traffic Server does _not_ cache objects with the following **request
+headers**:
+
+* `Authorization`: header
* `Cache-Control: no-store` header
+
* `Cache-Control: no-cache` header
To configure Traffic Server to ignore the `Cache-Control: no-cache` header,
- refer to [Configuring Traffic Server to Ignore Client no-cache Headers](#NoCacheHeaders).
+ refer to [Configuring Traffic Server to Ignore Client no-cache Headers](#ConfiguringTSIgnoreClientnocacheHeaders).
+
* `Cookie`: header (for text objects)
@@ -417,10 +408,8 @@ By default, Traffic Server does _not_ ca
cookied content that is of image type only. For more information,
refer to [Caching Cookied Objects](#CachingCookiedObjects).
-* `Authorization`: header
-
-#### Configuring Traffic Server to Ignore Client no-cache Headers #### {#ConfiguringTSIgnoreClientnocacheHeaders}
+### Configuring Traffic Server to Ignore Client no-cache Headers ### {#ConfiguringTSIgnoreClientnocacheHeaders}
By default, Traffic Server strictly observes client `Cache-Control: no-cache`
directives. If a requested object contains a `no-cache` header, then Traffic
@@ -429,14 +418,14 @@ in cache. You can configure Traffic Serv
such that it ignores `no-cache` headers from client requests and serves the
object from its cache.
-##### To configure Traffic Server to ignore client `no-cache` headers: ##### {#configureTSignoreclientnocacheheaders}
+To configure Traffic Server to ignore client `no-cache` headers
-3. In [`records.config`](../configuration-files/records.config)
-4. edit [_`proxy.config.cache.ignore_client_no_cache`_](../configuration-files/records.config#proxy.config.cache.ignore_client_no_cache)
+3. Edit the following variable in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.cache.ignore_client_no_cache`_](../configuration-files/records.config#proxy.config.cache.ignore_client_no_cache)
6. Run the command `traffic_line -x` to apply the configuration changes.
-### Origin Server Directives ### {#OriginServerDirectives}
+## Origin Server Directives ## {#OriginServerDirectives}
By default, Traffic Server does _not_ cache objects with the following **response**
**headers**:
@@ -457,23 +446,23 @@ By default, Traffic Server does _not_ ca
* `Expires`: header with value of 0 (zero) or a past date
-#### Configuring Traffic Server to Ignore Server **no-cache** Headers #### {#ConfiguringTSIgnoreServernocacheHeaders}
+### Configuring Traffic Server to Ignore Server no-cache Headers #### {#ConfiguringTSIgnoreServernocacheHeaders}
-By default, Traffic Server strictly observes `Cache-Control:no-cache` directives.
+By default, Traffic Server strictly observes `Cache-Control: no-cache` directives.
A response from an origin server with a `no-cache` header is not stored in
the cache and any previous copy of the object in the cache is removed. If you
configure Traffic Server to ignore `no-cache` headers, then Traffic Server
-also ignores `no-store` headers. The default behavior of observing `no-cache`
+also ignores `no-`**`store`** headers. The default behavior of observing `no-cache`
directives is appropriate in most cases.
-##### To configure Traffic Server to ignore server `no-cache` headers: ##### {#configureTSignoreserver`no-cache`headers}
+To configure Traffic Server to ignore server `no-cache` headers
-3. In [`records.config`](../configuration-files/records.config)
-4. edit [_`proxy.config.cache.ignore_server_no_cache`_](../configuration-files/records.config#proxy.config.cache.ignore_server_no_cache)
+3. Edit the following variable in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.cache.ignore_server_no_cache`_](../configuration-files/records.config#proxy.config.cache.ignore_server_no_cache)
6. Run the command `traffic_line -x` to apply the configuration changes.
-#### Configuring Traffic Server to Ignore WWW-Authenticate Headers #### {#ConfiguringTSIgnoreWWWAuthenticateHeaders}
+### Configuring Traffic Server to Ignore WWW-Authenticate Headers ### {#ConfiguringTSIgnoreWWWAuthenticateHeaders}
By default, Traffic Server does not cache objects that contain `WWW-Authenticate`
response headers. The `WWW-Authenticate` header contains authentication parameters
@@ -487,14 +476,14 @@ for future requests. However, the defaul
Server to ignore server `WWW-Authenticate` headers if you are knowledgeable
about HTTP 1.1.
-##### To configure Traffic Server to ignore server `WWW-Authenticate` headers: ##### {#configureTSignoreserverWWWAuthenticateheaders}
+To configure Traffic Server to ignore server `WWW-Authenticate` headers
-3. In [`records.config`](../configuration-files/records.config)
-4. edit [_`proxy.config.cache.ignore_authentication`_](../configuration-files/records.config#proxy.config.cache.ignore_authentication)
+3. Edit the following variable in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.cache.ignore_authentication`_](../configuration-files/records.config#proxy.config.cache.ignore_authentication)
6. Run the command `traffic_line -x` to apply the configuration changes.
-### Configuration Directives ### {#ConfigurationDirectives}
+## Configuration Directives ## {#ConfigurationDirectives}
In addition to client and origin server directives, Traffic Server responds to directives
you specify through configuration options and files.
@@ -505,46 +494,50 @@ You can configure Traffic Server to do t
* Cache **dynamic content** - that is, objects with URLs that end in **`.asp`** or contain a question mark (**`?`**),
semicolon (**`;`**), or **`cgi`**. For more information, refer to [Caching Dynamic Content](#CachingDynamicContent).
* Cache objects served in response to the `Cookie:` header (refer to [Caching Cookied Objects)](#CachingCookiedObjects).
-* Observe never-cache rules in the `cache.config` file (refer to [`records.config`](../configuration-files/records.config)).
+* Observe `never-cache` rules in the [`cache.config`](../configuration-files/cache.config) file.
-#### Disabling HTTP Object Caching #### {#DisablingHTTPObjectCaching}
+### Disabling HTTP Object Caching ### {#DisablingHTTPObjectCaching}
By default, Traffic Server caches all HTTP objects except those for which you
-have set never-cache rules in the `cache.config` file. You can disable HTTP
+have set [`never-cache`](../configuration-files/cache.config#action) rules in the
+[`cache.config`](../configuration-files/cache.config) file. You can disable HTTP
object caching so that all HTTP objects are served directly from the origin
server and never cached, as detailed below.
-##### To disable HTTP object caching manually: ##### {#disableHTTPobjectcachingmanually}
+To disable HTTP object caching manually
-3. In [`records.config`](../configuration-files/records.config)
-4. edit [_`proxy.config.cache.http`_](../configuration-files/records.config#proxy.config.cache.http)
+3. Edit the following variable in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.cache.http`_](../configuration-files/records.config#proxy.config.cache.http)
6. Run the command `traffic_line -x` to apply the configuration changes.
-#### Caching Dynamic Content #### {#CachingDynamicContent}
+### Caching Dynamic Content ### {#CachingDynamicContent}
A URL is considered **dynamic** if it ends in **`.asp`** or contains a question
mark (**`?`**), a semicolon (**`;`**), or **`cgi`**. By default, Traffic Server
-does _not_ cache dynamic content. You can configure Traffic Server to cache
-dynamic content, although it's recommended for specialized proxy situations only.
+caches dynamic content. You can configure the system to ignore dyanamic looking
+content, although this is recommended only if the content is *truely* dyanamic,
+but fails to advertise so with appropriate `Cache-Control` headers.
-##### To configure Traffic Server to cache dynamic content: ##### {#configureTScachedynamiccontent}
+To configure Traffic Server's cache behaviour in regard to dynamic content
-3. In [`records.config`](../configuration-files/records.config)
-4. edit [_`proxy.config.cache_urls_that_look_dynamic`_](../configuration-files/records.config#proxy.config.cache_urls_that_look_dynamic)
+3. Edit the following variable in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.http.cache.cache_urls_that_look_dynamic`_](../configuration-files/records.config#proxy.config.http.cache.cache_urls_that_look_dynamic)
6. Run the command `traffic_line -x` to apply the configuration changes.
-#### Caching Cookied Objects #### {#CachingCookiedObjects}
+### Caching Cookied Objects ### {#CachingCookiedObjects}
+
+<!-- XXX This should be extended to xml as well! -->
By default, Traffic Server caches objects served in response to requests that
-contain cookies (unless the object is text). Traffic Server does not cache
-cookied text content because object headers are stored along with the object,
-and personalized cookie header values could be saved with the object. With
-non-text objects, it is unlikely that personalized headers are delivered or
-used.
+contain cookies. This is true for all types of objects except for text.
+Traffic Server does not cache cookied text content because object headers are
+stored along with the object, and personalized cookie header values could be
+saved with the object. With non-text objects, it is unlikely that personalized
+headers are delivered or used.
You can reconfigure Traffic Server to:
@@ -552,67 +545,58 @@ You can reconfigure Traffic Server to:
* Cache cookied content that is of image type only.
* Cache all cookied content regardless of type.
-##### To configure how Traffic Server caches cookied content: ##### {#configurehowTScachescookiedcontent}
+To configure how Traffic Server caches cookied content
-3. In [`records.config`](../configuration-files/records.config)
-4. edit [_`proxy.config.cache_responses_to_cookies`_](../configuration-files/records.config#proxy.config.cache_responses_to_cookies)
+3. Edit the following variable in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.cache_responses_to_cookies`_](../configuration-files/records.config#proxy.config.cache_responses_to_cookies)
6. Run the command `traffic_line -x` to apply the configuration changes.
-## Forcing Object Caching ## {#ForcingObjectCaching}
+# Forcing Object Caching # {#ForcingObjectCaching}
You can force Traffic Server to cache specific URLs (including dynamic URLs)
for a specified duration, regardless of `Cache-Control` response headers.
-##### To force document caching: ##### {#forcedocumentcaching}
+To force document caching
-1. In [`cache.config`](../configuration-files/cache.config)
-2. Add a rule in the file for each URL you want Traffic Server to pin in the cache, as shown below.
+1. Add a rule for each URL you want Traffic Server to pin to the cache [`cache.config`](../configuration-files/cache.config):
- url_regex=URL ttl-in-cache=6h
+ :::text
+ url_regex=^https?://(www.)?apache.org/dev/ ttl-in-cache=6h
5. Run the command `traffic_line -x` to apply the configuration changes.
-## Caching HTTP Alternates ## {#CachingHTTPAlternates}
+# Caching HTTP Alternates # {#CachingHTTPAlternates}
Some origin servers answer requests to the same URL with a variety of objects.
The content of these objects can vary widely, according to whether a server
delivers content for different languages, targets different browsers with different
-presentation styles, or provides different document formats (HTML, PDF). Different
+presentation styles, or provides different document formats (HTML, XML). Different
versions of the same object are termed **alternates** and are cached by Traffic
Server based on `Vary` response headers. You can specify additional request
-and response headers for specific content types that Traffic Server will identify
+and response headers for specific `Content-Type`s that Traffic Server will identify
as alternates for caching. You can also limit the number of alternate versions
of an object allowed in the cache.
-### Configuring How Traffic Server Caches Alternates ### {#ConfiguringHowTSCachesAlternates}
-
+## Configuring How Traffic Server Caches Alternates ## {#ConfiguringHowTSCachesAlternates}
-##### To configure how Traffic Server caches alternates, follow the steps below: ##### {#configurehowTScachesalternates}
-3. In [`records.config`](../configuration-files/records.config)
-4. set [_`proxy.config.cache.enable_default_vary_headers`_](../configuration-files/records.config#proxy.config.cache.enable_default_vary_headers) to `1`
- to cache alternate versions of HTTP objects that do not contain the Vary header.
-4. set [_`proxy.config.cache.vary_default_text`_](../configuration-files/records.config#proxy.config.cache.vary_default_text) to to specify the HTTP
- header field on which you want to vary if the request is for text: for example, an HTML document.
-4. set [_`proxy.config.cache.vary_default_images`_](../configuration-files/records.config#proxy.config.cache.vary_default_images) to to specify the HTTP
- header field on which you want to vary if the request is for images: for example, a `.gif` file.
-4. set [_`proxy.config.cache.vary_default_other`_](../configuration-files/records.config#proxy.config.cache.vary_default_other) to to specify the HTTP
- header field on which you want to vary if the request is for anything other than text or image.
-
-4. **Note:** If you specify `Cookie` as the header field on which to vary in the above variables,
- then make sure that the variable [_`proxy.config.cache.cache_responses_to_cookies`_](../configuration-files/records.config#proxy.config.cache.cache_responses_to_cookies) is set appropriately.
-
- For example, if you set [_`proxy.config.cache.cache_responses_to_cookies`_](../configuration-files/records.config#proxy.config.cache.cache_responses_to_cookies) to
- 2 (cache responses to cookies of image type only) and set the [_`proxy.config.cache.vary_default_text`_](../configuration-files/records.config#proxy.config.cache.vary_default_text)
- variable to specify cookie, then alternates by cookie will not apply to text.
+To configure how Traffic Server caches alternates, follow the steps below
+3. Edit the following variables in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.http.cache.enable_default_vary_headers`_](../configuration-files/records.config#proxy.config.http.cache.enable_default_vary_headers)
+ * [_`proxy.config.http.cache.vary_default_text`_](../configuration-files/records.config#proxy.config.http.cache.vary_default_text)
+ * [_`proxy.config.http.cache.vary_default_images`_](../configuration-files/records.config#proxy.config.cache.vary_default_images)
+ * [_`proxy.config.http.cache.vary_default_other`_](../configuration-files/records.config#proxy.config.http.cache.vary_default_other)
7. Run the command `traffic_line -x` to apply the configuration changes.
+**Note:** If you specify `Cookie` as the header field on which to vary in the above variables,
+make sure that the variable [_`proxy.config.cache.cache_responses_to_cookies`_](../configuration-files/records.config#proxy.config.cache.cache_responses_to_cookies) is set appropriately.
-### Limiting the Number of Alternates for an Object ### {#LimitingNumberofAlternatesforanObject}
+
+## Limiting the Number of Alternates for an Object ## {#LimitingNumberofAlternatesforanObject}
You can limit the number of alternates Traffic Server can cache per object
(the default is 3).
@@ -622,15 +606,14 @@ performance because all alternates have
can look up the URL in the index very quickly, it must scan sequentially through
available alternates in the object store.
-##### To limit the number of alternates: ##### {#limitnumberofalternates}
+To limit the number of alternates
-3. In [`records.config`](../configuration-files/records.config)
-4. set [_`proxy.config.cache.limits.http.max_alts`_](../configuration-files/records.config#proxy.config.cache.limits.http.max_alts)
- to specify the maximum number of alternate versions of an object you want Traffic Server to cache.
+3. Edit the following variable in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.cache.limits.http.max_alts`_](../configuration-files/records.config#proxy.config.cache.limits.http.max_alts)
6. Run the command `traffic_line -x` to apply the configuration changes.
-## Using Congestion Control ## {#UsingCongestionControl}
+# Using Congestion Control # {#UsingCongestionControl}
The **Congestion Control** option enables you to configure Traffic Server to
stop forwarding HTTP requests to origin servers when they become congested.
@@ -639,20 +622,13 @@ server later.
To use the **Congestion Control** option, you must perform the following tasks:
-* Enable the Congestion Control option.
-* Create rules in the `congestion.config` file to specify:
+3. Set the following variable in [`records.config`](../configuration-files/records.config)
+ * [_`proxy.config.http.congestion_control.enabled`_](../configuration-files/records.config#proxy.config.http.congestion_control.enabled) to `1`
+* Create rules in the [`congestion.config`](../configuration-files/congestion.config) file to specify:
* which origin servers Traffic Server tracks for congestion
- the timeouts Traffic Server uses, depending on whether a server is congested
- the page Traffic Server sends to the client when a server becomes congested
- if Traffic Server tracks the origin servers per IP address or per hostname
-
-
-##### To enable and configure the Congestion Control option: ##### {#enableconfigureCongestionControloption}
-
-3. In [`records.config`](../configuration-files/records.config)
-4. set [_`proxy.config.http.congestion_control.enabled`_](../configuration-files/records.config#proxy.config.http.congestion_control.enabled)
- to 1 to enable the congestion control option.
-3. In [`congestion.config`](../configuration-files/congestion.config)
-6. Enter rules to specify which origin servers are tracked for congestion and the timeout values Traffic Server uses to determine congestion.
+* the timeouts Traffic Server uses, depending on whether a server is congested
+* the page Traffic Server sends to the client when a server becomes congested
+* if Traffic Server tracks the origin servers per IP address or per hostname
9. Run the command `traffic_line -x` to apply the configuration changes.
+
Modified: trafficserver/site/branches/ats-cms/content/docs/trunk/admin/index.en.mdtext
URL: http://svn.apache.org/viewvc/trafficserver/site/branches/ats-cms/content/docs/trunk/admin/index.en.mdtext?rev=1124427&r1=1124426&r2=1124427&view=diff
==============================================================================
--- trafficserver/site/branches/ats-cms/content/docs/trunk/admin/index.en.mdtext (original)
+++ trafficserver/site/branches/ats-cms/content/docs/trunk/admin/index.en.mdtext Wed May 18 20:55:12 2011
@@ -1,5 +1,5 @@
Doc: Apache Traffic Server
-Title: Administrators's Guide
+Title: Administrators's Guide - Overview
Notice: Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
@@ -19,6 +19,8 @@ Notice: Licensed to the Apache Softwa
Navigation: [Next](*)
[SDK](../sdk/index.en.html)
+<!-- TODO: Remove all references of different protocols here, since we only support one.
+ https is just a different scheme:// of the same protocol: HTTP -->
# Overview # {#overview}
@@ -27,14 +29,10 @@ performance, and delivers unprecedented
This chapter discusses the following topics:
-* [What Is Apache Traffic Server?](#what-is-ats)
-* [Traffic Server Deployment Options](#deployment-options)
-* [Traffic Server Components](#ats-components)
-* [Traffic Analysis Options](#traffic-analysis)
-* [Traffic Server Security Options](#security)
+[TOC]
-## What Is Apache Traffic Server? ## {#what-is-ats}
+# What Is Apache Traffic Server? # {#what-is-ats}
Global data networking has become part of everyday life: internet users
request billions of documents and terabytes of data, on a daily basis,
@@ -53,7 +51,7 @@ for enterprises, Internet service provid
and large intranets by maximizing existing and available bandwidth.
-## Traffic Server Deployment Options ## {#deployment-options}
+# Traffic Server Deployment Options # {#deployment-options}
To best suit your needs, Traffic Server can be deployed in several ways:
@@ -62,10 +60,11 @@ To best suit your needs, Traffic Server
* In a cache hierarchy
The following sections provide a summary of these Traffic Server
-deployment options.
+deployment options. Please keep in mind that with every of these options
+Traffic Server can be run as a *single instance*, or as a *multi-node cluster*.
-### Traffic Server as a Web Proxy Cache ### {#web-proxy-cache}
+## Traffic Server as a Web Proxy Cache ## {#web-proxy-cache}
As a web proxy cache, Traffic Server receives user requests for web
content as those requests travel to the destined web server (origin
@@ -78,10 +77,10 @@ satisfy future requests.
Traffic Server provides explicit proxy caching, in which the userâs
client software must be configured to send requests directly to Traffic
Server. Explicit proxy caching is described in the
-[Explicit Proxy Caching](explicit-proxy-caching) section.
+[Explicit Proxy Caching](explicit-proxy-caching) chapter.
-### Traffic Server as a Reverse Proxy ### {#reverse-proxy}
+## Traffic Server as a Reverse Proxy ## {#reverse-proxy}
As a reverse proxy, Traffic Server is configured to be the origin
server to which the user is trying to connect (typically, the origin
@@ -91,7 +90,7 @@ server acceleration. Reverse proxy is de
[Reverse Proxy and HTTP Redirects](reverse-proxy-http-redirects).
-### Traffic Server in a Cache Hierarchy ### {#cache-hierachy}
+## Traffic Server in a Cache Hierarchy ## {#cache-hierachy}
Traffic Server can participate in flexible cache hierarchies, in which
Internet requests not fulfilled from one cache are routed to other
@@ -105,14 +104,14 @@ Hierarchical caching is described in mor
[Hierarchical Caching](hierachical-caching).
-## Traffic Server Components ## {#ats-components}
+# Traffic Server Components # {#ats-components}
Traffic Server consists of several components that work together to
form a web proxy cache you can easily monitor and configure. These main
components are described below.
-### The Traffic Server Cache ### {#ats-server-cache}
+## The Traffic Server Cache ## {#ats-server-cache}
The Traffic Server cache consists of a high-speed object database
called the object store. The object store indexes objects according to
@@ -133,7 +132,7 @@ servers. For more information about the
[Configuring the Cache](configuring-cache).
-### The RAM Cache ### {#ram-cache}
+## The RAM Cache ## {#ram-cache}
Traffic Server maintains a small RAM cache that contains extremely
popular objects. This RAM cache serves the most popular objects as fast
@@ -143,7 +142,7 @@ for detailed information, refer to
[Changing the Size of the RAM Cache](configuring-cache#ChangingSizeRAMCache).
-### The Host Database ### {#host-db}
+## The Host Database ## {#host-db}
The Traffic Server host database stores the domain name server (DNS)
entries of origin servers to which Traffic Server connects to fulfill
@@ -158,7 +157,7 @@ the host database tracks:
wait for servers that are not running)
-### The DNS Resolver ### {#dns-resolver}
+## The DNS Resolver ## {#dns-resolver}
Traffic Server includes a fast, asynchronous DNS resolver to streamline
conversion of hostnames to IP addresses. Traffic Server implements the
@@ -168,37 +167,40 @@ queries can be issued in parallel and a
popular bindings in memory, DNS traffic is reduced.
-### Traffic Server Processes ### {#traffic-server-processes}
+## Traffic Server Processes ## {#traffic-server-processes}
Traffic Server contains three processes that work together to serve
-Traffic Server requests and manage/control/monitor the health of the
-Traffic Server system. The three processes are described below:
+requests and manage/control/monitor the health of the system.
+The three processes are described below:
-* The traffic\_server process is the transaction processing engine of
+* The `traffic_server` process is the transaction processing engine of
Traffic Server. It is responsible for accepting connections,
processing protocol requests, and serving documents from the cache
or origin server.
-* The traffic\_manager process is the command and control facility of
+
+* The `traffic_manager` process is the command and control facility of
the Traffic Server, responsible for launching, monitoring, and
- reconfiguring the traffic\_server process. The traffic\_manager
+ reconfiguring the `traffic_server` process. The `traffic_manager`
process is also responsible for the proxy autoconfiguration port,
the statistics interface, cluster administration, and virtual IP
failover.
- If the traffic\_manager process detects a traffic\_server process
+
+ If the `traffic_manager` process detects a `traffic_server` process
failure, it instantly restarts the process but also maintains a
connection queue of all incoming requests. All incoming connections
that arrive in the several seconds before full server restart are
saved in the connection queue and processed in first-come,
first-served order. This connection queueing shields users from any
server restart downtime.
-* The traffic\_cop process monitors the health of both the
- traffic\_server and traffic\_manager processes. The traffic\_cop
+
+* The `traffic_cop` process monitors the health of both the
+ `traffic_server` and `traffic_manager` processes. The `traffic_cop`
process periodically (several times each minute) queries the
- traffic\_server and traffic\_manager process by issuing heartbeat
+ `traffic_server` and `traffic_manager` process by issuing heartbeat
requests to fetch synthetic web pages. In the event of failure (if
no response is received within a timeout interval or if an
- incorrect response is received), traffic\_cop restarts the
- traffic\_manager and traffic\_server processes.
+ incorrect response is received), `traffic_cop` restarts the
+ `traffic_manager` and `traffic_server` processes.
The figure below illustrates the three Traffic Server processes.
@@ -206,7 +208,7 @@ The figure below illustrates the three T
-### Administration Tools ### {#admin-tools}
+## Administration Tools ## {#admin-tools}
Traffic Server offers the following administration options:
@@ -222,37 +224,43 @@ Traffic Server offers the following admi
through a simple file-editing and signal-handling interface. Any
changes you make through Traffic Line or Traffic Shell are
automatically made to the configuration files as well.
+* Finally there is a clean C API which can be put to good use from
+ a multitude of languages. The Traffic Server Admin Client
+ demonstrates this for Perl.
-## Traffic Analysis Options ## {#traffic-analysis}
+# Traffic Analysis Options # {#traffic-analysis}
Traffic Server provides several options for network traffic analysis
and monitoring:
* Traffic Line and Traffic Shell enable you to collect and process
statistics obtained from network traffic information.
+
* Transaction logging enables you to record information (in a log
file) about every request Traffic Server receives and every error
it detects. By analyzing the log files, you can determine how many
- people used the Traffic Server cache, how much information each
- person requested, and what pages were most popular. You can also
+ clients used the Traffic Server cache, how much information each
+ of them requested, and what pages were most popular. You can also
see why a particular transaction was in error and what state the
Traffic Server was in at a particular time; for example, you can
see that Traffic Server was restarted or that cluster communication
timed out.
- Traffic Server supports several standard log file formats, such as
+
+ Traffic Server supports several standard log file formats, such as
Squid and Netscape, and its own custom format. You can analyze the
standard format log files with off-the-shelf analysis packages. To
help with log file analysis, you can separate log files so that
they contain information specific to protocol or hosts.
Traffic analysis options are described in more detail in
-[Monitoring Traffic](monitoring-traffic);
+[Monitoring Traffic](monitoring-traffic).
+
Traffic Server logging options are described in
[Working with Log Files](working-log-files).
-## Traffic Server Security Options ## {#security}
+# Traffic Server Security Options # {#security}
Traffic Server provides numerous options that enable you to establish
secure communication between the Traffic Server system and other
@@ -261,7 +269,7 @@ following:
* Control client access to the Traffic Server proxy cache.
* Configure Traffic Server to use multiple DNS servers to match your
- siteâs security configuration. For example, Traffic Server can use
+ site's security configuration. For example, Traffic Server can use
different DNS servers, depending on whether it needs to resolve
hostnames located inside or outside a firewall. This enables you to
keep your internal network configuration secure while continuing to