trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r790554 - in /websites/staging/trafficserver/trunk/content/docs/trunk: STATUS admin/hierachical-caching/index.en.html
Date Tue, 07 Jun 2011 08:55:17 GMT
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">&quot;parent1;parent2&quot;</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=&quot;parent1;parent2&quot;
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 -->
 



Mime
View raw message