You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@trafficserver.apache.org by bu...@apache.org on 2011/06/07 10:55:17 UTC
svn commit: r790554 - in
/websites/staging/trafficserver/trunk/content/docs/trunk: STATUS
admin/hierachical-caching/index.en.html
Author: buildbot
Date: Tue Jun 7 08:55:17 2011
New Revision: 790554
Log:
Staging update by buildbot
Modified:
websites/staging/trafficserver/trunk/content/docs/trunk/STATUS
websites/staging/trafficserver/trunk/content/docs/trunk/admin/hierachical-caching/index.en.html
Modified: websites/staging/trafficserver/trunk/content/docs/trunk/STATUS
==============================================================================
--- websites/staging/trafficserver/trunk/content/docs/trunk/STATUS (original)
+++ websites/staging/trafficserver/trunk/content/docs/trunk/STATUS Tue Jun 7 08:55:17 2011
@@ -60,7 +60,7 @@ getting-started - done
http-proxy-caching - done
reverse-proxy-http-redirects - done
explicit-proxy-caching - done
-hierachical-caching
+hierachical-caching - done (commented out ICP peering, because it's not really supported right now)
configuring-cache
monitoring-traffic
configuring-traffic-server
Modified: websites/staging/trafficserver/trunk/content/docs/trunk/admin/hierachical-caching/index.en.html
==============================================================================
--- websites/staging/trafficserver/trunk/content/docs/trunk/admin/hierachical-caching/index.en.html (original)
+++ websites/staging/trafficserver/trunk/content/docs/trunk/admin/hierachical-caching/index.en.html Tue Jun 7 08:55:17 2011
@@ -43,13 +43,18 @@
<p>Traffic Server can participate in cache hierarchies. Requests not fulfilled
in one cache are routed to other regional caches, thereby leveraging the contents
and proximity of nearby caches. </p>
-<p>This chapter discusses the following topics: </p>
+<div class="toc">
<ul>
+<li><a href="#HierarchicalCaching">Hierarchical Caching</a></li>
<li><a href="#UnderstandingCacheHierarchies">Understanding Cache Hierarchies</a></li>
-<li><a href="#ParentCaching">Parent Caching</a></li>
-<li><a href="#ICPPeering">ICP Peering</a></li>
+<li><a href="#ParentCaching">Parent Caching</a><ul>
+<li><a href="#ParentFailover">Parent Failover</a></li>
+<li><a href="#ConfiguringTSUseaParentCache">Configuring Traffic Server to Use a Parent Cache</a></li>
</ul>
-<h2 id="UnderstandingCacheHierarchies">Understanding Cache Hierarchies</h2>
+</li>
+</ul>
+</div>
+<h1 id="UnderstandingCacheHierarchies">Understanding Cache Hierarchies</h1>
<p>A cache hierarchy consists of cache levels that communicate with each other.
Traffic Server supports several types of cache hierarchies. All cache hierarchies
recognize the concept of <strong>parent</strong> and <strong>child</strong>. A parent cache is a cache
@@ -57,10 +62,10 @@ higher up in the hierarchy, to which Tra
child cache is a cache for which Traffic Server is a parent. </p>
<p>Traffic Server supports the following hierarchical caching options: </p>
<ul>
-<li><a href="#ParentCaching">Parent Caching</a></li>
-<li><a href="#ICPPeering">ICP (Internet Cache Protocol) Peering</a></li>
+<li><a href="#ParentCaching">Parent Caching</a>
+<!-- * klzzwxh:0026 --></li>
</ul>
-<h2 id="ParentCaching">Parent Caching</h2>
+<h1 id="ParentCaching">Parent Caching</h1>
<p>If a Traffic Server node cannot find a requested object in its cache, then
it searches a parent cache (which itself can search other caches) before finally
retrieving the object from the origin server. You can configure a Traffic Server
@@ -86,7 +91,7 @@ cache (until the data is stale or expire
the content from the origin server (or from another cache, depending on the
parentâs configuration). The parent caches the content and then sends a copy
to Traffic Server (its child), where it is cached and served to the client. </p>
-<h3 id="ParentFailover">Parent Failover</h3>
+<h2 id="ParentFailover">Parent Failover</h2>
<p>Traffic Server supports use of several parent caches. This ensures that if
one parent cache is not available, another parent cache can service client
requests. </p>
@@ -94,10 +99,10 @@ requests. </p>
Server detects when a parent is not available and sends missed requests to
another parent cache. If you specify more than two parent caches, then the
order in which the parent caches are queried depends upon the parent proxy
-rules configured in the <a href="files.htm#parent.config">parent.config</a> configuration
+rules configured in the <a href="../configuration-files/parent.config">parent.config</a> configuration
file. By default, the parent caches are queried in the order they are listed
in the configuration file. </p>
-<h3 id="ConfiguringTSUseaParentCache">Configuring Traffic Server to Use a Parent Cache</h3>
+<h2 id="ConfiguringTSUseaParentCache">Configuring Traffic Server to Use a Parent Cache</h2>
<p>To configure Traffic Server to use one or more parent caches, you must complete
the following steps: </p>
<ul>
@@ -108,13 +113,13 @@ the following steps: </p>
</ul>
<p><strong>Note:</strong> You need to configure the child cache only. No additional configuration
is needed for the Traffic Server parent cache. </p>
-<h5 id="ConfigureTSuseaparentcache">Configure Traffic Server to use a parent cache:</h5>
-<p>Edit the following variable <a href="../configuration-files/records.config#proxy.config.http.parent_proxy_routing_enable"><em><code>proxy.config.http.parent_proxy_routing_enable</code></em></a> in <code>records.config</code> file.</p>
+<p>Configure Traffic Server to use a parent cache by editing the following variable
+<a href="../configuration-files/records.config#proxy.config.http.parent_proxy_routing_enable"><em><code>proxy.config.http.parent_proxy_routing_enable</code></em></a> in <code>records.config</code> file.</p>
<p>Edit the <a href="../configuration-files/parent.config"><code>parent.config</code></a> file located in the Traffic Server <code>config</code> directory to set
parent proxy rules to specify the parent cache to which you want missed requests to be forwarded;</p>
<p>The following example configures Traffic Server to route all requests containing the regular expression <code>politics</code>
and the path <code>/viewpoint</code> directly to the origin server (bypassing any parent hierarchies):</p>
-<div class="codehilite"><pre><span class="n">url_regex</span><span class="o">=</span><span class="n">politics</span> <span class="n">prefix</span><span class="o">=/</span><span class="n">viewpoint</span> <span class="n">go_direct</span><span class="o">=</span><span class="n">true</span>
+<div class="codehilite"><pre>url_regex=politics prefix=/viewpoint go_direct=true
</pre></div>
@@ -122,51 +127,59 @@ and the path <code>/viewpoint</code> dir
with <code>http://host1</code> to the parent cache <code>parent1</code>. If <code>parent1</code> cannot serve the requests, then
requests are forwarded to <code>parent2</code>. Because <code>round-robin=true</code>, Traffic Server goes through the
parent cache list in a round-robin based on client IP address.</p>
-<div class="codehilite"><pre><span class="n">dest_host</span><span class="o">=</span><span class="n">host1</span> <span class="n">scheme</span><span class="o">=</span><span class="n">http</span> <span class="n">parent</span><span class="o">=</span><span class="s">"parent1;parent2"</span> <span class="n">round</span><span class="o">-</span><span class="n">robin</span><span class="o">=</span><span class="n">strict</span>
+<div class="codehilite"><pre>dest_host=host1 scheme=http parent="parent1;parent2" round-robin=strict
</pre></div>
<p>Run the command <code>traffic_line -x</code> to apply the configuration changes.</p>
-<h2 id="ICPPeering">ICP Peering</h2>
-<p>The Internet Cache Protocol (ICP) is used by proxy caches to exchange information
+<!-- As of yet, this is not supported.
+
+# ICP Peering # {#ICPPeering}
+
+The Internet Cache Protocol (ICP) is used by proxy caches to exchange information
about their content. ICP query messages ask other caches if they are storing
a particular URL; ICP response messages reply with a hit or miss answer. A
-cache exchanges ICP messages only with specific <strong>ICP peers</strong>, which are neighboring
-caches that can receive ICP messages. An ICP peer can be a <strong>sibling cache
-</strong>(which is at the same level in the hierarchy) or a <strong>parent cache</strong> (which
-is one level up in the hierarchy). </p>
-<p>If Traffic Server has ICP caching enabled, then it sends ICP queries to its
+cache exchanges ICP messages only with specific **ICP peers**, which are neighboring
+caches that can receive ICP messages. An ICP peer can be a **sibling cache
+**(which is at the same level in the hierarchy) or a **parent cache** (which
+is one level up in the hierarchy).
+
+If Traffic Server has ICP caching enabled, then it sends ICP queries to its
ICP peers when the HTTP request is a cache miss. If there are no hits but parents
exist, then a parent is selected using a round-robin policy. If no ICP parents
exist, then Traffic Server forwards the request to its HTTP parents. If there
are no HTTP parent caches established, then Traffic Server forwards the request
-to the origin server. </p>
-<p>If Traffic Server receives a hit message from an ICP peer, then Traffic Server
+to the origin server.
+
+If Traffic Server receives a hit message from an ICP peer, then Traffic Server
sends the HTTP request to that peer. However, it might turn out to be a cache
miss because the original HTTP request contains header information that is
not communicated by the ICP query. For example, the hit might not be the requested
alternate. If an ICP hit turns out to be a miss, then Traffic Server forwards
-the request to either its HTTP parent caches or to the origin server. </p>
-<p>To configure a Traffic Server node to be part of an ICP cache hierarchy, you
-must perform the following tasks: </p>
-<ul>
-<li>Determine if the Traffic Server can receive ICP messages only, or if it can send <em>and</em> receive ICP messages. </li>
-<li>Determine if Traffic Server can send messages directly to each ICP peer or send a single message on a specified multicast channel. </li>
-<li>Specify the port used for ICP messages. </li>
-<li>Set the ICP query timeout. </li>
-<li>Identify the ICP peers (siblings and parents) with which Traffic Server can communicate.</li>
-</ul>
-<h5 id="configureTSuseanICPcachehierarchy">To configure Traffic Server to use an ICP cache hierarchy:</h5>
-<p>Edit the following variables in <a href="../configuration-files/records.config"><code>records.config</code></a> file:</p>
-<ul>
-<li><a href="../configuration-files/records.config#proxy.config.icp.enabled"><em><code>proxy.config.icp.enabled</code></em></a></li>
-<li><a href="../configuration-files/records.config#proxy.config.icp.port"><em><code>proxy.config.icp.icp_port</code></em></a></li>
-<li><a href="../configuration-files/records.config#proxy.config.icp.multicast_enabled"><em><code>proxy.config.icp.multicast_enabled</code></em></a></li>
-<li><a href="../configuration-files/records.config#proxy.config.icp.query_timeout"><em><code>proxy.config.icp.query_timeout</code></em></a></li>
-</ul>
-<p>Edit <code>icp.config</code> file located in the Traffic Server <code>config</code> directory:
-For each ICP peer you want to identify, enter a separate rule in the <a href="../configuration-files/icp.config">icp.config</a> file.</p>
-<p>Run the command <code>traffic_line -x</code> to apply the configuration changes.</p>
+the request to either its HTTP parent caches or to the origin server.
+
+To configure a Traffic Server node to be part of an ICP cache hierarchy, you
+must perform the following tasks:
+
+* Determine if the Traffic Server can receive ICP messages only, or if it can send _and_ receive ICP messages.
+* Determine if Traffic Server can send messages directly to each ICP peer or send a single message on a specified multicast channel.
+* Specify the port used for ICP messages.
+* Set the ICP query timeout.
+* Identify the ICP peers (siblings and parents) with which Traffic Server can communicate.
+
+To configure Traffic Server to use an ICP cache hierarchy edit the following variables in [`records.config`](../configuration-files/records.config) file:
+
+* [_`proxy.config.icp.enabled`_](../configuration-files/records.config#proxy.config.icp.enabled)
+* [_`proxy.config.icp.icp_port`_](../configuration-files/records.config#proxy.config.icp.port)
+* [_`proxy.config.icp.multicast_enabled`_](../configuration-files/records.config#proxy.config.icp.multicast_enabled)
+* [_`proxy.config.icp.query_timeout`_](../configuration-files/records.config#proxy.config.icp.query_timeout)
+
+Edit `icp.config` file located in the Traffic Server `config` directory:
+For each ICP peer you want to identify, enter a separate rule in the [icp.config](../configuration-files/icp.config) file.
+
+Run the command `traffic_line -x` to apply the configuration changes.
+
+-->
</div>
</div><!-- main -->