trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mlib...@apache.org
Subject git commit: Thundering herd section-- source code block doesn't eval links. Trying line blocks instead
Date Mon, 07 Oct 2013 18:08:19 GMT
Updated Branches:
  refs/heads/master b352f4a41 -> 7ba121c9a


Thundering herd section-- source code block doesn't eval links. Trying line blocks instead


Project: http://git-wip-us.apache.org/repos/asf/trafficserver/repo
Commit: http://git-wip-us.apache.org/repos/asf/trafficserver/commit/7ba121c9
Tree: http://git-wip-us.apache.org/repos/asf/trafficserver/tree/7ba121c9
Diff: http://git-wip-us.apache.org/repos/asf/trafficserver/diff/7ba121c9

Branch: refs/heads/master
Commit: 7ba121c9ac87a90e874c726ddd134a45d10ebfe3
Parents: b352f4a
Author: Miles Libbey <mlibbey@apache.org>
Authored: Mon Oct 7 11:08:02 2013 -0700
Committer: Miles Libbey <mlibbey@apache.org>
Committed: Mon Oct 7 11:08:02 2013 -0700

----------------------------------------------------------------------
 doc/admin/http-proxy-caching.en.rst | 27 ++++++++++++++-------------
 1 file changed, 14 insertions(+), 13 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/trafficserver/blob/7ba121c9/doc/admin/http-proxy-caching.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/http-proxy-caching.en.rst b/doc/admin/http-proxy-caching.en.rst
index 27f1369..1be97d9 100644
--- a/doc/admin/http-proxy-caching.en.rst
+++ b/doc/admin/http-proxy-caching.en.rst
@@ -784,12 +784,13 @@ Read While Writer
 -----------------
 When Traffic Server goes to fetch something from origin, and upon receiving the response,
any number of clients can be allowed to start serving the partially filled cache object once
background_fill_completed_threshold % of the object has been received. The difference is that
Squid allows this as soon as it goes to origin, whereas ATS can not do it until we get the
complete response header. The reason for this is that we make no distinction between cache
refresh, and cold cache, so we have no way to know if a response is going to be cacheable,
and therefore allow read-while-writer functionality.
 
-The configurations necessary to enable this in ATS are::
+The configurations necessary to enable this in ATS are:
+
+|   CONFIG :ts:cv:`proxy.config.cache.enable_read_while_writer` ``INT 1``
+|   CONFIG :ts:cv:`proxy.config.http.background_fill_active_timeout` ``INT 0``
+|   CONFIG :ts:cv:`proxy.config.http.background_fill_completed_threshold` ``FLOAT 0.000000``
+|   CONFIG :ts:cv:`proxy.config.cache.max_doc_size` ``INT 0`` 
 
-   CONFIG :ts:cv:`proxy.config.cache.enable_read_while_writer` ``INT 1``
-   CONFIG :ts:cv:`proxy.config.http.background_fill_active_timeout` ``INT 0``
-   CONFIG :ts:cv:`proxy.config.http.background_fill_completed_threshold` ``FLOAT 0.000000``
-   CONFIG :ts:cv:`proxy.config.cache.max_doc_size` ``INT 0`` 
 All four configurations are required, for the following reasons:
 
 -  enable_read_while_writer turns the feature on. It's off (0) by default
@@ -801,11 +802,11 @@ Once all this enabled, you have something that is very close, but not
quite the
 
 Fuzzy Revalidation
 ------------------
-Traffic Server can be set to attempt to revalidate an object before it becomes stale in cache.
:file:`records.config` contains the settings::
+Traffic Server can be set to attempt to revalidate an object before it becomes stale in cache.
:file:`records.config` contains the settings:
 
-   CONFIG :ts:cv:`proxy.config.http.cache.fuzz.time` ``INT 240``
-   CONFIG :ts:cv:`proxy.config.http.cache.fuzz.min_time` ``INT 0``
-   CONFIG :ts:cv:`proxy.config.http.cache.fuzz.probability` ``FLOAT 0.005``
+|   CONFIG :ts:cv:`proxy.config.http.cache.fuzz.time` ``INT 240``
+|   CONFIG :ts:cv:`proxy.config.http.cache.fuzz.min_time` ``INT 0``
+|   CONFIG :ts:cv:`proxy.config.http.cache.fuzz.probability` ``FLOAT 0.005``
 
 For every request for an object that occurs "fuzz.time" before (in the example above, 240
seconds) the object is set to become stale, there is a small
 chance (fuzz.probability == 0.5%) that the request will trigger a revalidation request to
the origin. For objects getting a few requests per second, this would likely not trigger,
but then this feature is not necessary anyways since odds are only 1 or a small number of
connections would hit origin upon objects going stale. The defaults are a good compromise,
for objects getting roughly 4 requests / second or more, it's virtually guaranteed to trigger
a revalidate event within the 240s. These configs are also overridable per remap rule or via
a plugin, so can be adjusted per request if necessary.  
@@ -819,7 +820,7 @@ These configurations are similar to Squid's refresh_stale_hit configuration
opti
 
 
 Open Read Retry Timeout
-------------------
+-----------------------
 
 The open read retry configurations attempt to reduce the number of concurrent requests to
the origin for a given object. While an object is being fetched from the origin server, subsequent
requests would wait open_read_retry_time milliseconds before checking if the object can be
served from cache. If the object is still being fetched, the subsequent requests will retry
max_open_read_retries times. Thus, subsequent requests may wait a total of (max_open_read_retries
x open_read_retry_time) milliseconds before establishing an origin connection of its own.
For instance, if they are set to 5 and 10 respectively, connections will wait up to 50ms for
a response to come back from origin from a previous request, until this request is allowed
through.
 
@@ -829,9 +830,9 @@ Similarly, this setting should be used in conjunction with Read While
Writer for
 
 Since ATS now supports setting these settings per-request or remap rule, you can configure
this to be suitable for your setup much more easily.
 
-The configurations are (with defaults)::
+The configurations are (with defaults):
 
-   CONFIG :ts:cv:`proxy.config.http.cache.max_open_read_retries` ``INT -1``
-   CONFIG :ts:cv:`proxy.config.http.cache.open_read_retry_time` ``INT 10``
+|   CONFIG :ts:cv:`proxy.config.http.cache.max_open_read_retries` ``INT -1``
+|   CONFIG :ts:cv:`proxy.config.http.cache.open_read_retry_time` ``INT 10``
 
 The default means that the feature is disabled, and every connection is allowed to go to
origin instantly. When enabled, you will try max_open_read_retries times, each with a open_read_retry_time
timeout.


Mime
View raw message