Why Apache Traffic Server

Title: Why Apache Traffic Server
Notice:    Licensed to the Apache Software Foundation (ASF) under one
           or more contributor license agreements.  See the NOTICE file
           distributed with this work for additional information
           regarding copyright ownership.  The ASF licenses this file
           to you under the Apache License, Version 2.0 (the
           "License"); you may not use this file except in compliance
           with the License.  You may obtain a copy of the License at
           .
             
           .
           Unless required by applicable law or agreed to in writing,
           software distributed under the License is distributed on an
           "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
           KIND, either express or implied.  See the License for the
           specific language governing permissions and limitations
           under the License.

The two main reasons to use Apache Traffic Server is the same as to use
any other caching proxy server: 

* It brings - potentially dynamic - content closer to your customers.

* By caching the content such a server can remain simple in nature and
  specialize in the delivery of such cached, and thus *static* content.



Most caching proxy servers fulfill these requirements. Apache Traffic
Server may be particularity suited to your needs because:

# Fast # {#fast}

...it's fast! On cheap hardware we have measured up to *190k QPS for
a 10k object*. In big setups it's only NIC bound.

The reason why it can be so fast is Traffic Server's architecture: e.g.:
make sure that in the critical path between the client's request and
the server's response there is no memory allocation, simply because especially
on high loads it would slow the response down.

Our recommended setup stores the cache RAW to the disk. There are two reasons
for doing this: The first is to circumvent the VFS internal structures. These
structures are very well suited for traversing a file-system, but they are not
very well suited for efficiently storing and retrieving a huge amount of objects
as quickly as possibly.

The second reason for reading and writing to a RAW disk rather than into a file-system
may seem counter-intuitive: To circumvent the VFS' caching. The VFS "naturally"
caches files that processes running on the system access and will hold them
in an LRU in the RAM. This space however is precious and on a busy system something
that ATS considers important may well be swapped out from the LRU. The reason for
the choice to circumvent existing structures and caching facilities in favor for
its own, specialized is so we can more concretely manage expectations of performance.

Another architectural choice that makes Apache Traffic Server shine performance wise
is auto-scaling:

# Scalable # {#scalable}

By default Traffic Server automatically scales to the available resources of
the hardware. While the program itself is event-oriented, it uses mutliple
specialized threads for each task, and scales them accordingy to the
available hardware.

| **Thread Group** | **Scaling**
|NET | [proxy.config.exec_thread.autoconfig.scale](/docs/trunk/admin/configuration-files/records.config#proxy.config.exec_thread.autoconfig.scale) × CPU cores
|SSL | [proxy.config.exec_thread.autoconfig.scale](/docs/trunk/admin/configuration-files/records.config#proxy.config.exec_thread.autoconfig.scale) × CPU cores
|STORE | [proxy.config.cache.threads_per_disk](/docs/trunk/admin/configuration-files/records.config#proxy.config.cache.threads_per_disk) × Disks

If scaling ATS on a single node (vertically) no longer suffices a logical
choice is to scale to multiple nodes (horizontally):

* explain parent caching
* explain clustering
* explain that ICP is broken and needs your help ;)

# Extensible # {#extensible}

While Traffic Server's core is fairly simple in nature each of the states
that it goes through is extensible by plugins.



These days such plugins can be written in a number of languages. Aside from
the obvious choices of C and C++ which is the server's native tongue, we also
support C++11 and Lua. These languages make it easier to write short, readable
code. With Lua in particular it is even possible for inexperienced programmers
to quickly prototype an extension.



Generally speaking there are three types of plugins:

* **Remap** - modify the request URL or the origin (e.g.: [mysql_remap](/docs/trunk/admin/plugins/mysql_remap)
* **Transform** - modify the response itself (e.g.: [gzip](/docs/trunk/admin/plugins/gzip)
* **Protocol** - provide a different protocol (e.g.: [spdy](/docs/trunk/admin/plugins/spdy)

# Comparing Apache Traffic Server to its competition # {#competition}

|                |  ATS  |  Varnish  |  httpd  |  nginx  |  Squid  |
|----------------|----:|--------:|------:|------:|------:|
| Worker Threads | ?   | ?       | ?     | ×     | ?     |
| Multi-Process  | ×   | ?       | ?     | ?     | ?     |
| Event-driven   | ?   | ×       | ?     | ?     | ?     |
| Plugin-API     | ?   | ?       | ?     | ?     | ~     |
| Reverse Proxy  | ?   | ?       | ?     | ?     | ?     |
| Forward Proxy  | ?   | ×       | ?     | ?     | ?     |
| Transparent    | ?   | ×       | ×     | ×     | ?     |
| TLS            | ?   | ×       | ?     | ?     | ?     |
| Load Balancing | ×   | ?       | ?     | ?     | ?     |
| Cache          | ?   | ?       | ?     | ?     | ?     |
| ESI            | ?   | ?       | ×     | ×     | ×     |
| ICP            | ~   | ?       | ?     | ?     | ?     |
| Parental Cache | ?   | ?       | ×     | ?     | ?     |
| WCCP           | ?   | ×       | ×     | ×     | ?     |
| SPDY           | ?   | ×       | ×     | ?     | ×     |
| Keep-Alive     | ?   | ?       | ?     | ?     | ?     |
| Pipeline       | ?   | ×       | ?     | ?     | ?     |

*[ATS]: Apache Traffic Server
*[LRU]: Last Recently Used