Page History

...

The following lists the steps involved in taking a generic configuration,
and modifying it for my own needs. Yours may vary, however, and I'll do my best
to indicate which settings should be sized based on your install.

NOTE: My goal here is to give myself the most aggressive caching at the highest throughput possible.

All three Wiki pages use configuration examples from my running home Traffic Server setup.

...

There's an algorithm here that I don't fully understand, but this setting should guarantee that objects
loaded in the background are cached regardless of their size.

From Leif H: "This recommendation is wrong, it should be set to 0.0 for it to always kick in. It allows the server to continue fetching / caching a large object even if the client disconnects. This setting (with a value of 0.0) is a prerequisite for getting read-while-writer to kick in."

CONFIG proxy.config.http.background_fill_completed_threshold FLOAT 0.000000

HTTP Cache Options

The default config for ATS specifies that after 1 day(86,400 seconds), any object without a specific expiration
cannot be cached. I'd prefer that they stick around for about 3 months. This setting is contentious in that what it should be is debatable.

From Leif H: "The proxy.config.http.cache.heuristic_max_lifetime is mostly correct, except for two things: 1) It does not get “flushed”, it merely says how long (max) it can cache objects under the heuristics rules. 2) It’s not a fixed setting, what it does is together with the “min” setting is to get a range for the Expire time, the effective TTL will be a value between min-max, based on how old the object is (based on Last-Modified). Since you set lm_factor=1.0, you did effectively set min == max == 3 months. This seems very aggressive, and counteracts how the heuristics system is supposed to work. The idea is that objects which are changing frequently you should cache much shorter than those which change infrequently."

True, these settings may not be for everyone.

CONFIG proxy.config.http.cache.heuristic_max_lifetime INT 7776000

There's an algorithm here that I don't fully understand, but this setting should guarantee that the relevant
information regarding an object's "last modified" date is fully support by the cache.

CONFIG proxy.config.http.cache.heuristic_lm_factor FLOAT 1.000000

Fuzzy Object Expiration Logic

From Leif H: "As described here, is not what it does, at all. Fuzzy logic is there to allow (random chance) a client to go to origin before the object is stale in cache. The idea is that you would (for some reasonably active objects) prefetch the object such that you always have it fresh in cache."

An interesting notion, but not one I desire. The following setting disables this feature.

...

CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 115
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 115
CONFIG proxy.config.http.transaction_no_activity_timeout_in INT 90
CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 90
CONFIG proxy.config.http.transaction_active_timeout_in INT 43200
CONFIG proxy.config.http.transaction_active_timeout_out INT 43200
CONFIG proxy.config.http.accept_no_activity_timeout INT 30

HTTP Cache Options

The following settings are pretty important. I'll go through them one at a time.

This one defines a global variable whose function is to indicate whether specific HTTP headers
are necessary to properly cache an object. As it turns out, much of this functionality is
included in HTTP 1.1 and thus additional headers aren't really necessary.

CONFIG proxy.config.http.cache.required_headers INT 0

they are necessary.

From Leif H: "PLEASE, do no set this to 0 unless you own both the cache and the origin. In “0”, it allows everything to be cached, unless it’s explicitly denied. This is a direct violation of RFC2616, and will in forward proxy, will certainty break things where more than one user is behind the cache. Set it to “1”, which can still break for poorly behaved web sites (e.g. amazon.com used to break with it set to “1”, which is why we set it to “2”."

My mistake...I had no idea this violated an RFC. This has been duly updatedThe next specifies how "stale" an object should be before it gets fetched again from the Internet.
The default config for ATS specifies that after 1 week(604800 seconds), any object that is "stale"
should be flushed from the cache. I'd prefer that it stick around for about 3 months.

CONFIG proxy.config.http.cache.maxrequired_stale_ageheaders INT 77760001

This one specifies whether or not to allow clients to use HTTP "range" requests. While having this option enabled
will save bandwidth, it also slows page loading.

...

From Leif H: "Turning off proxy.config.http.cache.range.lookup

...

The default config for ATS specifies that after 1 day(86,400 seconds), any object without a specific expiration
should be flushed from the cache. I'd prefer that it stick around for about 3 months. This setting is contentious
in that what it should be is debatable.(range requests) does not tell ATS that it can’t use Range: requests. It completely disabled Range: support for all clients. This is almost never what you want . Leave it on."

CONFIG proxy.config.http.cache.heuristic_max_lifetime.range.lookup INT 7776000

There's an algorithm here that I don't fully understand, but this setting should guarantee that the relevant
information regarding an object's "last modified" date is fully support by the cache.

CONFIG proxy.config.http.cache.heuristic_lm_factor FLOAT 1.000000

0

HTTP RAM Cache

While the default ATS options for this may be optimal under heavy load,
I found using the simpler LRU algorithm much faster and more useful.

...

This setting is pretty important. It defines a global variable whose function is to both structure the cache
for future objects, as well as optimize other areas.

From Leif H: "Your setting for proxy.config.cache.min_average_object_size seems wrong. If your average object size is 32KB, you should set this to, hem, 32KB . However, to give some headroom, my personal recommendation is to 2x the number of directory entries, so set the configuration to 16KB.

The math is mostly correct, except the calculation for "Disk Cache Object Capacity” is in fact the max number of directory entries the cache can hold. Each object on disk consumes at least one directory entry, but can consume more."

As it turns out, my original thoughts on this were a bit misguided.

For my purposes, I decided an "average Internet object"
is roughly 32KB in size, and so we can do the following math:

Average Internet Object Size: 32KB
Disk Cache Size: 3GB
Disk Cache Size In Bytes: 3221225472 (3 * 1024 * 1024 * 1024)
Average Internet Object Size In Bytes: 32768 (32 * 1024)
Disk Cache Object Capacity: 98304 (3221225472 / 32768 Directory Entries Required Per Object(headroom): 2
Cache Minimum Average Object Size: 16384 (32768 / 2)

CONFIG proxy.config.cache.min_average_object_size INT 96K16K

NOTE: This setting should be sized relative to the size of your disk cache.
Also, it requires clearing the disk cache and restarting ATS to properly take effect.

...

CONFIG proxy.config.cache.mutex_retry_delay INT 5025

Maximum Concurrent DNS Queries

...

CONFIG proxy.config.hostdb.size INT 8K
CONFIG proxy.config.hostdb.storage_size INT 4M

DNS Host Cache Database Timeout

The default config for ATS specifies that after 1 day(1,440 minutes), all DNS records should be flushed
from the cache. I'd prefer that they stick around for about 3 months.

CONFIG proxy.config.hostdb.timeout INT 129600

HTTP Socket I/O Buffers

The default config for ATS leaves these disabled. I believe these to be somewhat useful
for HTTP streaming applications such as Internet Radio and YouTube. However,
setting these too large tends to slow down the cache overall.

...