Apache Traffic Server 〜1週間ほど動かしてみて

使い始めて、1週間弱経過したわけですが。>Apache Traffic Server
朧気ながら、Squidとの違いも見えてきたので、気がついたことをいくつかメモ的に、書きだしてみます。

少なくとも、体感的にはTraffic ServerのほうがSquidよりも心持ち速いかなぁ、という印象を受けています。
定量的な測定はしていないので、ほんとにどっちが速いのかはわかりませんが、多分マルチスレッド化されているか否か、という点での違いが大きそうです。

psコマンドでは、そのあたりが分かりにくいので、"pstree -Gc root"で取得したプロセスの状態を比較してみると一目瞭然。
squidは、

     ├─squid3───squid3─┬─diskd
     │                 └─unlinkd

と、psの結果とほぼ同じになりますが、Traffic Serverのほうは、

     ├─traffic_cop───traffic_manager─┬─traffic_server─┬─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                ├─{traffic_server}
     │                               │                └─{traffic_server}
     │                               ├─{traffic_manage}
     │                               ├─{traffic_manage}
     │                               ├─{traffic_manage}
     │                               ├─{traffic_manage}
     │                               ├─{traffic_manage}
     │                               ├─{traffic_manage}
     │                               ├─{traffic_manage}
     │                               └─{traffic_manage}

と細かいスレッドに分割されていることがわかります。
マルチスレッド化されていることで、マルチコア環境ではかなり威力を発揮するんじゃないかなぁ、という感じなのでテストしてみる価値がありそうです。


ログに関しても、

デフォルトではbinary形式になっていて、いささか面倒なので、これをASCII形式に変更するために"1"をセット。

Apache Traffic Server ~実運用に向けての設定 - Soukaku's HENA-CHOKO Blog

と思っていたのだけど、"traffic_logcat"と"traffic_logstats"というコマンドの存在に気がついたので、ASCII形式でなくてもいい、という結論になりました。
"traffic_logcat"コマンドを使えば、

# traffic_logcat /var/log/trafficserver/squid.blog  | head -n5
1304343056.266 131 172.16.0.101 TCP_MISS/200 3548 GET http://www.google.com/uds/GnewsSearch?callback=google.search.NewsSearch.RawCompletion&context=1&rsz=small&hl=ja&source=uds-nb-horizontal&gss=.jp&sig=da11a17ee21435ab38fe3d34c57b4e8b&q=%25E3%2582%25A2%25E3%2583%2583%25E3%2583%2597%25E3%2583%25AB&key=notsupplied&v=1.0&nocache=1304342201693 - DIRECT/www.google.com text/javascript -
1304343058.394 335 172.16.0.101 TCP_MISS/200 1091 GET http://api.twitter.com/1/statuses/user_timeline.json?screen_name=Soukaku&callback=TWTR.Widget.receiveCallback_1&include_rts=true&count=5&since_id=65037238404251648&refresh=true&clientsource=TWITTERINC_WIDGET&1304342878050=cachebust - DIRECT/api.twitter.com application/json -
1304343058.425 985 172.16.0.101 TCP_MISS/200 24520 GET http://api.twitter.com/1/Soukaku/lists/librahack/statuses.json?per_page=80 - DIRECT/api.twitter.com application/json -
1304343058.436 997 172.16.0.101 TCP_MISS/200 19080 GET http://api.twitter.com/1/Soukaku/lists/bunkyo-ku-18/statuses.json?per_page=80 - DIRECT/api.twitter.com application/json -
1304343063.357 1005 172.16.0.101 TCP_MISS/200 14165 GET http://api.twitter.com/1/statuses/mentions.json?count=40 - DIRECT/api.twitter.com application/json -

バイナリ形式のデータをASCII形式に変換できるし、"traffic_logstats"コマンドを使えば、バイナリ形式のログを集計して、キャッシュヒット率を表示してくれる。
下記の例では、実行結果の先頭25行を抜き出しているけど、ヒット率以外にも、HTTPレスポンスコード別集計や、HTTPメソッド別、コンテントタイプ集計も同時に行なってくれるので、日々の運用で結構使えそうです。
#念のため、全部出力した結果は、こちら

# traffic_logstats -s | head -n 25
                        Totals (all Origins combined)
Request Result                         Count    Percent       Bytes    Percent
------------------------------------------------------------------------------
Cache hit                              5,925     13.61%     93.38MB     19.03%
Cache hit IMS                          2,220      5.10%    743.96KB      0.15%
Cache hit refresh                      3,367      7.73%      5.49MB      1.12%
Cache hit other                            0      0.00%      0.00KB      0.00%
Cache hit total                       11,512     26.44%     99.60MB     20.30%
Cache miss                            26,410     60.65%    358.93MB     73.15%
Cache miss IMS                         3,720      8.54%     13.25MB      2.70%
Cache miss refresh                     1,285      2.95%     18.49MB      3.77%
Cache miss other                           0      0.00%      0.00KB      0.00%
Cache miss total                      31,415     72.15%    390.68MB     79.62%
Client aborted                           226      0.52%    248.10KB      0.05%
Connect failed                           261      0.60%    123.90KB      0.02%
Invalid request                            8      0.02%      1.70KB      0.00%
Unknown error(99)                          0      0.00%      0.00KB      0.00%
Other errors                               0      0.00%      0.00KB      0.00%
Errors total                             495      1.14%    373.70KB      0.07%
..............................................................................
Total requests                        43,544    100.00%    490.69MB    100.00%

アクセス制御のあたりは、まだ試すことが出来ていないので、近いうちにそちらもやってみたいと思います。

トラックバック(0)

コメントする