svn commit: r1408101 - /trafficserver/site/trunk/content/why-ats.mdtext

[ig...@apache.org]

Author: igalic
Date: Sun Nov 11 19:48:48 2012
New Revision: 1408101

URL: http://svn.apache.org/viewvc?rev=1408101&view=rev
Log:
Add a basic outline of "why use ATS"

This is basically igalic and humbedooh's talk from ApacheCon.eu/2012
It should be understood as a reference point to various piece of the
existing documentation.

Added:
    trafficserver/site/trunk/content/why-ats.mdtext

Added: trafficserver/site/trunk/content/why-ats.mdtext
URL: http://svn.apache.org/viewvc/trafficserver/site/trunk/content/why-ats.mdtext?rev=1408101&view=auto
==============================================================================
--- trafficserver/site/trunk/content/why-ats.mdtext (added)
+++ trafficserver/site/trunk/content/why-ats.mdtext Sun Nov 11 19:48:48 2012
@@ -0,0 +1,101 @@
+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
+           .
+             http://www.apache.org/licenses/LICENSE-2.0
+           .
+           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.
+
+<!-- this could also need Daniel's fancy graphics explaining how Proxies rule (the world) -->
+
+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.
+
+<!-- link to the hooks picture in the SDK -->
+
+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.
+
+<!-- link to the Lua and C++11 API docs and examples! -->
+
+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)
+
+*[ATS]: Apache Traffic Server
+*[LRU]: Last Recently Used