You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@trafficserver.apache.org by ml...@apache.org on 2013/09/26 20:32:34 UTC
[1/4] git commit: Clarified connect to orign based on users@ question
Updated Branches:
refs/heads/master 128c64579 -> 9ce9ab912
Clarified connect to orign based on users@ question
Project: http://git-wip-us.apache.org/repos/asf/trafficserver/repo
Commit: http://git-wip-us.apache.org/repos/asf/trafficserver/commit/8e11d382
Tree: http://git-wip-us.apache.org/repos/asf/trafficserver/tree/8e11d382
Diff: http://git-wip-us.apache.org/repos/asf/trafficserver/diff/8e11d382
Branch: refs/heads/master
Commit: 8e11d3829aa8eb824f02ae6e52cf93f5c0eed0da
Parents: be93cfb
Author: Miles Libbey <ml...@apache.org>
Authored: Wed Aug 21 11:35:59 2013 -0700
Committer: Miles Libbey <ml...@apache.org>
Committed: Wed Aug 21 11:35:59 2013 -0700
----------------------------------------------------------------------
doc/admin/reverse-proxy-http-redirects.en.rst | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/trafficserver/blob/8e11d382/doc/admin/reverse-proxy-http-redirects.en.rst
----------------------------------------------------------------------
diff --git a/doc/admin/reverse-proxy-http-redirects.en.rst b/doc/admin/reverse-proxy-http-redirects.en.rst
index 54fb3ed..bacc03e 100644
--- a/doc/admin/reverse-proxy-http-redirects.en.rst
+++ b/doc/admin/reverse-proxy-http-redirects.en.rst
@@ -142,8 +142,7 @@ The figure above demonstrates the following steps:
advertised hostname resolves to Traffic Server).
2. Traffic Server locates a map rule in the ``remap.config`` file and
remaps the request to the specified origin server (``realhost.com``).
-3. Traffic Server opens an HTTP connection to the origin server. (This
- step is optional)
+3. Traffic Server opens an HTTP connection to the origin server. (If the request is not able to be served from cache)
4. If the request is a cache hit and the content is fresh, then Traffic
Server sends the requested object to the client from the cache.
Otherwise, Traffic Server obtains the requested object from the
[4/4] git commit: Bit of grammar changes
Posted by ml...@apache.org.
Bit of grammar changes
Project: http://git-wip-us.apache.org/repos/asf/trafficserver/repo
Commit: http://git-wip-us.apache.org/repos/asf/trafficserver/commit/9ce9ab91
Tree: http://git-wip-us.apache.org/repos/asf/trafficserver/tree/9ce9ab91
Diff: http://git-wip-us.apache.org/repos/asf/trafficserver/diff/9ce9ab91
Branch: refs/heads/master
Commit: 9ce9ab91292851abba05783e3e332975c0929a60
Parents: 4d629cc
Author: Miles Libbey <ml...@apache.org>
Authored: Thu Sep 26 10:25:44 2013 -0700
Committer: Miles Libbey <ml...@apache.org>
Committed: Thu Sep 26 10:25:44 2013 -0700
----------------------------------------------------------------------
doc/admin/http-proxy-caching.en.rst | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/trafficserver/blob/9ce9ab91/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 12f9e85..cbce259 100644
--- a/doc/admin/http-proxy-caching.en.rst
+++ b/doc/admin/http-proxy-caching.en.rst
@@ -780,9 +780,9 @@ When an object can not be served from cache, the request will be proxied to the
this can result in many near simultaneous requests to the origin server, potentially overwhelming it or associated
resources. There are several features in Traffic Server that can be used to avoid this scenario.
-Read While Write
-----------------
-When Traffic Server goes to fetch something from origin, and upon receiving the response, any number of clients can be allowed to start serving out of the partially filled cache object (it starts serving the 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-write functionality.
+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:
@@ -793,7 +793,7 @@ 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
-- The background fill feature must be allowed to kick in for every request. This is necessary, in case the owning consumer ("client session") goes away, someone needs to take over the session. The original client's request can go away after background_fill_active_timeout seconds, and the object will continue fetching in the background. The object then can start being served to another request after background_fill_completed_threshold % of the object has been fetched from origin.
+- The background fill feature should be allowed to kick in for every possible request. This is necessary, in case the writer ("first client session") goes away, someone needs to take over the session. The original client's request can go away after background_fill_active_timeout seconds, and the object will continue fetching in the background. The object then can start being served to another request after background_fill_completed_threshold % of the object has been fetched from origin.
- The proxy.config.cache.max_doc_size should be unlimited (set to 0), since the object size may be unknown, and going over this limit would cause a disconnect on the objects being served.
Once all this enabled, you have something that is very close, but not quite the same, as Squid's Collapsed Forwarding.
@@ -825,7 +825,7 @@ The open read retry configurations attempt to reduce the number of concurrent re
These settings are inappropriate when objects are uncacheable. In those cases, requests for an object effectively become serialized. The subsequent requests would await at least open_read_retry_time milliseconds before being proxies to the origin.
-Similarly, this setting should be used in conjunction with Read While Write for big (those that take longer than (max_open_read_retries x open_read_retry_time) milliseconds to transfer) cacheable objects. Without the read-while-write settings enabled, while the initial fetch is ongoing, not only would subsequent requests be delayed by the maximum time, but also, those requests would result in another request to the origin server.
+Similarly, this setting should be used in conjunction with Read While Writer for big (those that take longer than (max_open_read_retries x open_read_retry_time) milliseconds to transfer) cacheable objects. Without the read-while-writer settings enabled, while the initial fetch is ongoing, not only would subsequent requests be delayed by the maximum time, but also, those requests would result in another request to the origin server.
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.
[3/4] git commit: Added section on avoiding thundering herd of
requests
Posted by ml...@apache.org.
Added section on avoiding thundering herd of requests
Project: http://git-wip-us.apache.org/repos/asf/trafficserver/repo
Commit: http://git-wip-us.apache.org/repos/asf/trafficserver/commit/4d629cc9
Tree: http://git-wip-us.apache.org/repos/asf/trafficserver/tree/4d629cc9
Diff: http://git-wip-us.apache.org/repos/asf/trafficserver/diff/4d629cc9
Branch: refs/heads/master
Commit: 4d629cc922e49c797145a586a8d0f3f1574c3b24
Parents: cf03ec1
Author: Miles Libbey <ml...@apache.org>
Authored: Wed Sep 25 09:36:34 2013 -0700
Committer: Miles Libbey <ml...@apache.org>
Committed: Wed Sep 25 09:36:34 2013 -0700
----------------------------------------------------------------------
doc/admin/http-proxy-caching.en.rst | 64 +++++++++++++++++++++++++++++++-
1 file changed, 63 insertions(+), 1 deletion(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/trafficserver/blob/4d629cc9/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 1e60bb1..12f9e85 100644
--- a/doc/admin/http-proxy-caching.en.rst
+++ b/doc/admin/http-proxy-caching.en.rst
@@ -523,7 +523,7 @@ 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
-efault behavior of observing ``no-cache`` directives is appropriate
+default behavior of observing ``no-cache`` directives is appropriate
in most cases.
To configure Traffic Server to ignore server ``no-cache`` headers
@@ -773,3 +773,65 @@ be set to the same value.
If using c:func:`TSHttpTxnConfigIntSet`, it must be called no later than `TS_HTTP_READ_RESPONSE_HDR_HOOK`.
+Reducing Origin Server Requests (Avoiding the Thundering Herd)
+==============================================================
+
+When an object can not be served from cache, the request will be proxied to the origin server. For a popular object,
+this can result in many near simultaneous requests to the origin server, potentially overwhelming it or associated
+resources. There are several features in Traffic Server that can be used to avoid this scenario.
+
+Read While Write
+----------------
+When Traffic Server goes to fetch something from origin, and upon receiving the response, any number of clients can be allowed to start serving out of the partially filled cache object (it starts serving the 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-write functionality.
+
+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``
+All four configurations are required, for the following reasons:
+
+- enable_read_while_writer turns the feature on. It's off (0) by default
+- The background fill feature must be allowed to kick in for every request. This is necessary, in case the owning consumer ("client session") goes away, someone needs to take over the session. The original client's request can go away after background_fill_active_timeout seconds, and the object will continue fetching in the background. The object then can start being served to another request after background_fill_completed_threshold % of the object has been fetched from origin.
+- The proxy.config.cache.max_doc_size should be unlimited (set to 0), since the object size may be unknown, and going over this limit would cause a disconnect on the objects being served.
+
+Once all this enabled, you have something that is very close, but not quite the same, as Squid's Collapsed Forwarding.
+
+
+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:
+
+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.
+
+Note that if the revalidation occurs, the requested object is no longer available to be served from cache. Subsequent
+requests for that object will be proxied to the origin.
+
+Finally, the fuzz.min_time is there to be able to handle requests with a TTL less than fuzz.time – it allows for different times to evaluate the probability of revalidation for small TTLs and big TTLs. Objects with small TTLs will start "rolling the revalidation dice" near the fuzz.min_time, while objects with large TTLs would start at fuzz.time. A logarithmic like function between determines the revalidation evaluation start time (which will be between fuzz.min_time and fuzz.time). As the object gets closer to expiring, the window start becomes more likely. By default this setting is not enabled, but should be enabled anytime you have objects with small TTLs. Note that this option predates overridable configurations, so you can achieve something similar with a plugin or remap.config conf_remap.so configs.
+
+These configurations are similar to Squid's refresh_stale_hit configuration option.
+
+
+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.
+
+These settings are inappropriate when objects are uncacheable. In those cases, requests for an object effectively become serialized. The subsequent requests would await at least open_read_retry_time milliseconds before being proxies to the origin.
+
+Similarly, this setting should be used in conjunction with Read While Write for big (those that take longer than (max_open_read_retries x open_read_retry_time) milliseconds to transfer) cacheable objects. Without the read-while-write settings enabled, while the initial fetch is ongoing, not only would subsequent requests be delayed by the maximum time, but also, those requests would result in another request to the origin server.
+
+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):
+
+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.
[2/4] git commit: Merge branch 'master' of
https://git-wip-us.apache.org/repos/asf/trafficserver
Posted by ml...@apache.org.
Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/trafficserver
Project: http://git-wip-us.apache.org/repos/asf/trafficserver/repo
Commit: http://git-wip-us.apache.org/repos/asf/trafficserver/commit/cf03ec12
Tree: http://git-wip-us.apache.org/repos/asf/trafficserver/tree/cf03ec12
Diff: http://git-wip-us.apache.org/repos/asf/trafficserver/diff/cf03ec12
Branch: refs/heads/master
Commit: cf03ec1228ddac3943f2de603d7846f1ad6c48e7
Parents: 8e11d38 128c645
Author: Miles Libbey <ml...@apache.org>
Authored: Tue Sep 24 13:06:48 2013 -0700
Committer: Miles Libbey <ml...@apache.org>
Committed: Tue Sep 24 13:06:48 2013 -0700
----------------------------------------------------------------------
CHANGES | 95 ++-
Makefile.am | 2 +-
STATUS | 24 +-
Vagrantfile | 7 +-
build/tcl.m4 | 2 +-
build/xml.m4 | 81 +-
ci/Makefile | 21 -
ci/apache-rat-0.11-SNAPSHOT.jar | Bin 0 -> 1414641 bytes
ci/coverity-model.cc | 18 +
ci/jenkins.yaml | 486 ------------
ci/jenkins/Makefile | 21 +
ci/jenkins/jobs.yaml | 781 +++++++++++++++++++
ci/jenkins/records.config | 1 +
ci/rat-regex.txt | 39 +
configure.ac | 6 +-
contrib/manifests/debian.pp | 9 +
contrib/manifests/redhat.pp | 2 +-
doc/admin/configuring-cache.en.rst | 48 +-
doc/admin/event-logging-formats.en.rst | 123 ++-
doc/admin/faqs.en.rst | 174 ++---
doc/admin/getting-started.en.rst | 31 +-
doc/admin/http-proxy-caching.en.rst | 80 +-
doc/admin/traffic-server-error-messages.en.rst | 471 ++++++-----
doc/admin/transparent-proxy/bridge.en.rst | 111 +--
doc/admin/working-log-files.en.rst | 391 +++++-----
doc/admin/working-log-files/log-formats.en.rst | 35 +-
doc/arch/cache/cache-api.en.rst | 17 +
doc/arch/cache/cache-appendix.en.rst | 17 +
doc/arch/cache/cache-glossary.en.rst | 22 -
doc/arch/cache/cache.en.rst | 2 -
doc/arch/cache/common.defs | 17 +
doc/arch/cache/tier-storage.en.rst | 17 +
doc/conf.py | 4 +-
doc/ext/traffic-server.py | 20 +-
doc/glossary.en.rst | 60 ++
doc/index.rst | 27 +-
doc/reference/api/TSHttpHookAdd.en.rst | 49 +-
.../api/TSHttpOverridableConfig.en.rst | 70 ++
doc/reference/api/TSHttpTxnMilestoneGet.en.rst | 102 +--
doc/reference/api/TSLifecycleHookAdd.en.rst | 109 +++
doc/reference/api/TSPluginInit.en.rst | 6 +-
doc/reference/api/TSTypes.en.rst | 77 ++
doc/reference/api/index.en.rst | 33 +-
doc/reference/commands/traffic_cop.en.rst | 28 +-
.../configuration/logs_xml.config.en.rst | 104 +--
.../configuration/records.config.en.rst | 271 +++++--
.../configuration/storage.config.en.rst | 37 +-
doc/sdk/getting-started.en.rst | 2 +
doc/sdk/header-based-plugin-examples.en.rst | 2 +
.../how-to-create-trafficserver-plugins.en.rst | 2 +
doc/sdk/http-transformation-plugin.en.rst | 8 +-
doc/sdk/index.en.rst | 4 +
doc/sdk/new-protocol-plugins.en.rst | 65 +-
doc/sdk/preface.en.rst | 16 +-
iocore/cache/CacheWrite.cc | 1 +
iocore/cache/Notes | 18 +
iocore/dns/P_DNSConnection.h | 19 -
iocore/eventsystem/I_EventProcessor.h | 2 +-
iocore/eventsystem/P_UnixEventProcessor.h | 2 +-
iocore/eventsystem/UnixEThread.cc | 4 +
iocore/eventsystem/UnixEventProcessor.cc | 6 +-
iocore/net/P_Connection.h | 22 -
iocore/net/UnixNet.cc | 5 +
iocore/utils/Machine.cc | 10 +-
lib/perl/Makefile.am | 7 +-
lib/perl/lib/Apache/TS/AdminClient.pm | 1 +
lib/records/I_RecSignals.h | 3 -
lib/records/RecProcess.cc | 33 +
lib/ts/Allocator.h | 6 +-
lib/ts/EventNotify.cc | 83 +-
lib/ts/EventNotify.h | 15 +-
lib/ts/ink_inet.cc | 10 +-
lib/ts/ink_inet.h | 53 +-
lib/ts/ink_lockfile.h | 4 -
lib/tsconfig/Makefile.am | 2 +-
mgmt/Alarms.cc | 40 +-
mgmt/Alarms.h | 2 +-
mgmt/BaseManager.h | 3 -
mgmt/LocalManager.cc | 4 -
mgmt/RecordsConfig.cc | 126 ++-
mgmt/cluster/ClusterCom.cc | 119 ++-
mgmt/cluster/ClusterCom.h | 2 +
mgmt/stats/StatProcessor.cc | 30 +-
mgmt/stats/StatProcessor.h | 8 +
mgmt/stats/StatType.cc | 24 +
mgmt/stats/spec | 18 +
mgmt/utils/XmlUtils.cc | 61 +-
plugins/experimental/Makefile.am | 1 +
plugins/experimental/buffer_upload/Makefile.am | 21 +
.../experimental/buffer_upload/buffer_upload.cc | 58 +-
plugins/experimental/healthchecks/README | 4 +-
.../experimental/healthchecks/healthchecks.c | 46 +-
plugins/experimental/lua/state.cc | 5 +
plugins/experimental/rfc5861/rfc5861.c | 1 +
plugins/header_rewrite/Examples/Force-close | 2 +-
plugins/header_rewrite/README | 88 ++-
plugins/header_rewrite/header_rewrite.config | 94 ---
plugins/regex_remap/README | 12 +-
plugins/regex_remap/regex_remap.cc | 30 +-
proxy/InkAPI.cc | 15 +-
proxy/InkAPIInternal.h | 97 ++-
proxy/Main.cc | 12 +-
proxy/Main.h | 1 -
proxy/Makefile.am | 4 +-
proxy/StatSystem.h | 8 +
proxy/api/ts/experimental.h | 7 +-
proxy/api/ts/ts.h.in | 18 +-
proxy/config/records.config.default.in | 30 +-
proxy/config/stats.config.xml.default | 156 ++++
proxy/example_alarm_bin.sh | 50 +-
proxy/http/HttpDebugNames.cc | 4 +-
proxy/http/HttpSM.cc | 104 ++-
proxy/http/HttpSM.h | 2 +-
proxy/http/HttpTransact.cc | 74 +-
proxy/http/HttpTransact.h | 26 +-
proxy/http/HttpTunnel.cc | 2 +-
proxy/http/HttpUpdateSM.cc | 2 +-
proxy/logging/Log.cc | 104 ++-
proxy/logging/Log.h | 9 +-
proxy/logging/LogAccess.cc | 4 +-
proxy/logging/LogCollationClientSM.cc | 6 +
proxy/logging/LogCollationHostSM.cc | 11 +-
proxy/logging/LogConfig.cc | 319 ++++----
proxy/logging/LogConfig.h | 65 +-
proxy/logging/LogFile.cc | 42 +-
proxy/logging/LogFilter.cc | 7 +-
proxy/logging/LogHost.cc | 8 +
proxy/logging/LogObject.cc | 70 +-
proxy/logging/LogObject.h | 13 +-
proxy/msgs/TSMessages.mc | 83 --
proxy/msgs/TSMsgs.rc | 39 -
rc/trafficserver.in | 12 +-
tools/apichecker.pl | 179 ++++-
tools/jtest/jtest.cc | 1 -
tools/lighttpd_mod_generator/Makefile | 20 +
.../conf/lighttpd_11.conf | 17 +
.../conf/lighttpd_13.conf | 17 +
.../conf/lighttpd_15.conf | 17 +
.../conf/lighttpd_17.conf | 17 +
.../conf/lighttpd_19.conf | 17 +
.../conf/lighttpd_20.conf | 17 +
.../conf/lighttpd_22.conf | 17 +
.../conf/lighttpd_24.conf | 17 +
.../lighttpd_mod_generator/conf/lighttpd_3.conf | 17 +
.../lighttpd_mod_generator/conf/lighttpd_5.conf | 16 +
.../lighttpd_mod_generator/conf/lighttpd_7.conf | 16 +
.../lighttpd_mod_generator/conf/lighttpd_9.conf | 16 +
147 files changed, 4708 insertions(+), 2449 deletions(-)
----------------------------------------------------------------------