While the default configuration values for ATS will get you up and running,
at the moment they they're somewhat designed for regression testing and not real-world applications.

This page documents what I've discovered myself through a fair amount of experimentation
and experimentation and real-world experience.

The following lists the steps involved in taking a generic configuration,
and  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.

Current Home Machine

Please keep in mind the following only applies to creating a forward-only web proxy caching setup.

The following lists steps involved in taking a generic Traffic Server install and customizing it for my own needs.

NOTE:  Please use the following with Apache Traffic Server v5.0.0 and higher.

 Server Virtual Machine

• Server Host: Vultr (www.vultr.com)Make/Model: Apple iMac Mid 2011
• CPU: 3.4 6 Ghz Intel Core i7 CPU (quad-single core w/Hyperthreading)
• Memory: 8GB1GB
• Disk: 1TB20GB SSD
• OS: Mac OS X v10.8.5CentOS Linux 7.0
• Cache Size: 3GB

...

• : 1GB
• Browser: Google Chrome v43

Testing Regimen

The following settings have been tested against the following:

• IPv4 websites
• IPv6 websites
• Explicitly difficult web pages (i.e. Bing Image Search)
• Explicitly SSL web sites (i.e. Facebook)
• Internet Radio (various typesHTTP streaming, as well as iTunes Radio & Pandora)

The following settings are all located in /usr/local/etc/trafficserver/records.config. When adding lines, simply organize them in alphabetic sequence.

Step 1 – Disable Reverse Proxy

Reverse Proxy Settings

Since Traffic Server v5.0.0 has reorganized this file, I'll go through the relevant sections here.  When adding configurations, simply add the settings below the existing ones.

Thread Configuration

As I'm using ATS as purely a forward-only web proxy cacheTraffic Server on a personal basis, I decided to turn these off.
I believe the default settings enable ATS as both a forward and reverse cacheto explicitly configure it to not consume as many CPU cores as it might do otherwise.

If your situation is different, simply change proxy.config.exec_thread.limit to set how many CPU cores you'd like to use.

CONFIG proxy.config.reverseexec_proxythread.enabledautoconfig INT 0
CONFIG proxy.config.urlexec_remapthread.remap_requiredlimit INT 0

Step 2 – Configure

You may or may not wish to enable these configuration options.
They essentially make ATS more aggressive in caching than its default configuration would allow.

HTTP Background Fill Completion

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."

1

HTTP Connection Timeouts

I'm using Traffic Server on a speedy datacenter-grade connection.  As such, I've configured it to be pretty impatient in terms of timeouts.

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.

...

keep_alive_no_activity_timeout_in INT 900
CONFIG proxy.config.http.

...

I've since updated these settings.

keep_alive_no_activity_timeout_out INT 900
CONFIG proxy.config.http.cache.heuristic_min_lifetimetransaction_no_activity_timeout_in INT 25920005
CONFIG proxy.config.http.cache.heuristic_max_lifetimetransaction_no_activity_timeout_out INT 77760005
CONFIG proxy.config.http.cache.heuristic_lm_factor FLOAT 0.500000

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.

transaction_active_timeout_in INT 14400
CONFIG proxy.config.http.cache.fuzz.min_time INT 0

Step 3 – Optimize

Execution Threads

The default config for ATS supports as many CPU cores as you have in your machine.
Typically, ATS will configure 1.5 threads per CPU and automatically scale upwards.

I have 4, but discovered over time that using all of them causes problems with iTunes, and World of Warcraft.
In the hopes of avoiding problems like that, I decided to configure my ATS to use just one core where possible.

transaction_active_timeout_out INT 14400
CONFIG proxy.config.exec_thread.autoconfig.http.accept_no_activity_timeout INT 05
CONFIG proxy.config.exec_thread.limitnet.default_inactivity_timeout INT 1

HTTP Chunking

The default config for ATS specifies that the proxy itself use data "chunks" of 4KB each. Being that I'm on a
high-speed Internet link at home, I decided to increase this. I originally went with 64KB, only to find my
Internet Radio seemed to be having problems. 16KB should remedy that.

CONFIG proxy.config.http.chunking.size INT 16K

HTTP Connection Sharing

The default config for ATS specifies that outbound connections be shared within connection pools
on a per-thread basis. Fair enough. For some reason, though, this caused me no end of performance
problems. Thus, the following specifies one "global" connection pool which is much faster.

CONFIG proxy.config.http.share_server_sessions INT 1

Inbound And Outbound HTTP Connections

The default config for ATS sets these artificially low. I found that remote webservers themselves actually
slow down if more than 16 simultaneous connections are attempted. Also, most popular browsers support
up to 256 simultaneous connections from browser to proxy server so our ATS config should reflect that.

5

Network Settings

The following settings control various network-related settings within ATS.

The first setting controls how often Traffic Server will internally poll to process network events.  Even though I'm now on a machine that can handle 2-3% CPU load, I decided to reduce this.  I haven't noticed any significant performance difference as a result of this.

The second and third/fourth settings relate more closely to OS-tuning that's documented in the next wiki page.

The second setting removes the TCP_NODELAY option from origin server connections.  Once one has told Linux to optimize for latency, this appears to be no longer necessary.

The third/fourth settings specify the socket buffer sizes for origin server connections.  I've found setting this to roughly my "average object size" as reported by "traffic_top" appears to be optimal.

CONFIG proxy.config.net.poll_timeout INT 50

CONFIG proxy.config.http.origin_server_pipeline INT 16
CONFIG proxy.config.httpnet.usersock_option_agentflag_pipelineout INT 256

HTTP Connection Timeouts

I decided to use Mozilla Firefox's values here, along with one of my own.
It turns out proxy.config.http.transaction_active_timeout_in was essentially shutting down my
streaming Internet Radio connections. I increased that setting from 15 minutes to 12 hours.

0

Cache Control

The following configurations tell Traffic Server to be more aggressive than it would otherwise, with regard to caching overall as well as some speed-ups.

Also, I found that from a correctness point of view, my cache behaves better when not caching "dynamic" URLs.

CONFIG proxy.config.http.cache.keepcache_aliveurls_nothat_activitylook_timeout_indynamic INT 1150
CONFIG proxy.config.http.keep_alive_no_activity_timeout_outchunking.size INT 11564K
CONFIG proxy.config.http.cache.transactionims_no_activity_timeout_in INT 90
CONFIG proxy.config.http.transactionon_client_no_activity_timeout_outcache INT 900
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, 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 updated.

cache.ignore_server_no_cache INT 1

Heuristic Cache Expiration

The default config for Traffic Server 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 between 1-4 weeks. This setting is contentious in that what it should be is debatable.

The goal here is to enforce a window of between 1 and 4 weeks to keep objects in the cache, using Traffic Server's built-in heuristics.

CONFIG proxy.config.http.cache.requiredheuristic_min_headerslifetime INT 1

This one specifies whether or not to allow clients to use HTTP "range" requests.

...

604800
CONFIG proxy.config.http.cache.

...

heuristic_max_lifetime INT 2592000

Network Configuration

The default config for Traffic Server allows for up to 30,000 simultaneous connections.

I decided for my purposes that's pretty excessive.

CONFIG proxy.config.http.cache.range.lookupnet.connections_throttle INT 0
1K

...

RAM And Disk Cache Configuration

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

The following specifies 1GB of RAM cache, with objects of unlimited size,
to be managed using LRU. During normal use, RAM utilization will rise and rise
until all 1GB is used, then the LRU algorithm should kick in. Also,
figure on at least 100MB of general RAM overhead for ATS in addition to this.

config for Traffic Server specifies a few things here that can be tuned.

First, I decided to explicitly set my RAM cache settings.  If your situation is different, simply change proxy.config.ram_cache.size to set how much RAM you'd like to use.

Second, I observed my cache running via the "traffic_top" utility and have set the average object size accordingly.

NOTE:  One should always halve the setting for that configuration, as it allows "headroom" within Traffic Server such that one will never run out of slots in which to store objects.

CONFIG proxy.config.cache.ram_cache.size INT 1G8M
CONFIG proxy.config.cache.ram_cache_cutoff INT 01M
CONFIG proxy.config.cache.ram_cache.algorithm INT 1
CONFIG proxy.config.cache.rammin_cache.useaverage_seenobject_filtersize INT 0

NOTE: This setting should be sized relative to the amount of memory you want to use.
Also, it requires restarting ATS to properly take effect.

Cache Minimum Average Object Size

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.

...

24K
CONFIG proxy.config.cache.

...

target_

...

fragment_size

...

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
Directory Entries Required Per Object(headroom): 2
Cache Minimum Average Object Size: 16384 (32768 / 2)

 INT 4M
CONFIG proxy.config.cache.mutex_retry_delay INT 50
CONFIG proxy.config.cache.minenable_averageread_objectwhile_sizewriter INT 16K

NOTE: This setting requires clearing the disk cache and restarting ATS to properly take effect.

Cache Threads Per Disk Spindle

My setting here is somewhat of a rough guess. I've had issues in the past with Squid as a web cache
and increasing the threads dedicated to disk access definitely helped. However, with ATS I've actually
noticed a speed boost by decreasing this setting. My current theory is that this setting should allow
for one thread per CPU core.

2

Logging Configuration

The defaults for Traffic Server specify a squid-compatible logfile that's binary in nature.  I prefer to have the file readable so I'm overriding this.

CONFIG proxy.config.cachelog.threadssquid_log_peris_diskascii INT 1

...

HostDB Configuration

The default setting for ATS is unfortunately quite low. For some reason this caused a repeatable,
large delay when loading Bing Image Search results. The following setting removes most of the delays
and seems to speed up the cache overall a bit.

CONFIG proxy.config.cache.mutex_retry_delay INT 25

Maximum Concurrent DNS Queries

The default settings for ATS regarding DNS are set pretty high. I decided for my purposes to lower them,
Your Milage May Vary on these.

CONFIG proxy.config.dns.max_dns_in_flight INT 512

DNS Internet Protocol Preference

I've no idea if this setting really helps or not, but I like to specify my preference for IPv6 over IPv4
as much as possible.

defaults for Traffic Server configure the disk-based DNS cache to be rather large.  First, I found I got a decent speed improvement by sizing this down.

Second, I specifically prefer IPv6 over IPv4.  This simply tells the cache to prefer the newer IPv6 when possible.

Third, I also allow the cache to use stale DNS records for up to 60 seconds while they're being updated.  This also contributes to cache speed.

If your situation is different, simply get to know the following settings.  It takes a bit of practice to get used to, but they're all tunable.

##############################################################################
# HostDB
##############################################################################

CONFIG proxy.config.hostdb.ip_resolve STRING ipv6;ipv4

DNS Host Cache Database Size

The default settings for ATS regarding DNS are set pretty high. I think the following represents a pretty
good balance between caching too much and caching too little in terms of DNS.

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

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.

12M
CONFIG proxy.config.nethostdb.sockserve_send_buffer_size_instale_for INT 060
CONFIG proxy.config.net.sock_recv_buffer_size_in INT 0
CONFIG proxy.config.net.sock_send_buffer_size_out INT 0
CONFIG proxy.config.net.sock_recv_buffer_size_out INT 128K

Step 3 – Secure

Maximum Inbound Concurrent Connections

The default config for ATS specifies that this server can handle up to 30,000 connections.
For my purposes, that's a bit excessive. I figure with 1,024 connections there's plenty
of "elbow room".

CONFIG proxy.config.net.connections_throttle INT 1K

cache.hostdb.sync_frequency INT 900

Restart Traffic Server

Once you've updated the relevant records.config settings, simply refresh your disk cache if necessary and then restart Traffic Server.

After that's been done, enjoy your newly-tuned proxy server.

sudo /usr/local/bin/trafficserver stop
sudo /usr/local/bin/trafficserver start

Previous Page:  WebProxyCacheSetup

Next Page: WebProxyCacheOSThat's it. Go ahead and refresh your cache(if necessary), restart ATS, and enjoy your tuned proxy server.