A life with Programming

Antiwebの設計 - プロセス

2011-05-18T08:59:00.008+09:00

パフォーマンスとセキュリティのために、Antiwebは一群のunixプロセスである。本稿は異なるプロセスの役割と責任を述べる。

下図はプロセスと実行中のAntiwebシステムの責任を図示したものである。

ハブ(Hub)プロセス

ハブプロセスは通常、Antiwebシステムにおいてもっとも忙しいプロセスである。その責務は以下のとおり。

unixソケットを通じて新しい接続を受け付ける。その接続はワーカープロセスにつなげられるか、あるいはスーパーバイザ接続につなげられるかする。
インターネットからHTTP接続を受け付ける。リクエストされた仮想ホスト(vhost)に基づいて接続を適用すべきワーカーを決定し、接続から読み込んだデータをunixソケット越しにワーカーに流す。このプロセスで、ハブプロセス中のソケットを閉じるので、そのソケットはワーカーにおいてのみ開かれていることになる。
ワーカープロセスからのすべてのログメッセージを受け取り、それをロガープロセスに転送する。
プロセス間メッセージをルーティングする(たとえばスーパーバイザ接続)。

他にハブについて注記すること:

ハブプロセスは、ハブ設定ファイルにおいて指定されたユーザないしUIDにおいて動作する。
そのプロセスが権限を持たない空ディレクトリに対してchroot()される。

（訳注：Antiwebがどれほどセキュリティを意識しているかを述べている。）

ロガー(Logger)プロセス

ロガープロセスはハブプロセスとunixソケットで接続している。その唯一の仕事はハブプロセスからログメッセージを受け取って、それらをディスクに書き込むことである。ワーカーがログプロセスを作ると、それがハブを通じてロガープロセスにルーティングされる。

ハブ設定ファイルにおいて指定されたユーザないしUIDにおいて動作する。
書き込み権限を持つaw_logディレクトリにchroot()される。
ロガープロセスはログファイルをchmod()するので、ログファイルは全体に読み書き可となることはけっしてない。

ワーカー(Worker)プロセス

ワーカープロセスはHTTPリクエスト処理の重量挙げを行なう。

worker confに指定されたユーザないしUIDにおいて動作する。
オプションとして chroot()される。
クライアントソケットと接続して転送されるので、ワーカープロセスは後続のHTTPリクエストをこれらのソケットにおいて処理する。それらはハブを経由しない。

Antiweb Tip
なぜ複数のワーカーを動作させたいか？

権限を分けたvhosts
SMP/マルチコア
ディスクレイテンシの縮小

起動時、各ワーカープロセスはその設定ファイルを読み、HTTPリクエストをディスパッチするための関数をコンパイルする。この関数は与えられたマウントポイントとその他の存在する機能を処理する。起動後、ワーカープロセスはこの設定ファイルを二度と開かない。新しい設定ファイルを提供する唯一の方法は、スーパーバイザプロセスを使ってメッセージを送ることである。これは設定ファイルを含まないルートにワーカーをchroot()させるために不可欠のことだ。
ハブによってそのワーカープロセスが関心を持つべきvhostsを登録すると、そのワーカープロセスはハブ接続を「ロック」して追加のvhostsを登録できないようにする。vhostsを後で追加するには、その接続は手動でスーパーバイザプロセスからアンロックしなければならない(これは、ワーカー設定を-reloadするときに舞台裏で起きることだ --- これと関係する unlikely attack の可能性を見よ)。正しくないワーカー設定を-reloadさせようとすると、Antiwebは新しい設定をインストールせず、もとの設定を使い続ける。ワーカー設定を-reloadしてそれが正しくコンパイルされたが、HTTPリクエストの処理中に何かエラーが生じた場合、Antiwebはワーカーを殺してその理由をsyslogに記録する。

権限の分割

ワーカープロセスが自身に属していないvhostsの接続を盗むことはできない。
ワーカープロセスが他のワーカーによって作られたログメッセージをインターセプトすることはできない。

Antiwebの設計 - メモリ管理

2011-05-18T06:59:00.003+09:00

Antiwebにおいてもっとも重要なメモリ管理システムはlispのガベージコレクタである。AntiwebをサポートするCommon Lispの実装の多くは、すばらしいガベージコレクタを持っているので、負荷の高いベンチマーク以外ではけっして止まっているように見えることはないはずである。

lispの外側では、Antiwebは2つの重要なデータ構造 conns および ioblocks を持つ。これらのデータ構造はファイルsrc/libantiweb.hに定義されている。拡張子と関係なく、これはCのヘッダファイルではない。lispとCコンパイラの双方でパースできる特殊な書式である。

Antiwebプロセスによって使われているメモリのを-roomコマンドでブレークダウンすることができる。CMUCLを使ってワーカを探索する様子を以下に示す。

# antiweb -room /var/aw/example.conf

"---ANTIWEB MEMORY STATS---
Dynamic Space Usage:        1,946,272 bytes (out of  512 MB).
Read-Only Space Usage:     24,024,304 bytes (out of  256 MB).
Static Space Usage:         3,665,792 bytes (out of  256 MB).
Control Stack Usage:            1,636 bytes (out of  128 MB).
Binding Stack Usage:               88 bytes (out of  128 MB).
The current dynamic space is 0.
Garbage collection is currently enabled.

conns and ioblocks:
Allocated conns:     2, 470 bytes
Allocated ioblocks:  1, 4112 bytes, 14 in use, 99.7% overhead
Free conns:          2, 470 bytes
Free ioblocks:       514, 2113568 bytes
Total:               2118620 bytes + malloc overhead
---END OF ANTIWEB MEMORY STATS---"

ファイル src/libantiweb.c を読んでみると、Antiwebがconn構造体とioblock構造体をmalloc()しながら、それらをけっしてfree()しないことに気づくであろう。Antiwebは、その構造体を使い終わったら、それをフリーリストにプッシュする。次に必要になったときは、直近にフリーリストにプッシュしたものをポップする。connおよびioblock構造体は常に同一の大きさであるので、これがAntiwebに可能なのである。

メモリの解放は危険とみなす

上記の -room の出力において、connおよびioblockの数値は高水位に表示されている。トラフィックが重いとき、より多くのメモリが割り当てられる。トラフィックが落ち着くと、フリーリストの底の方は必要に応じてカーネルによってスワップアウトされる。

Antiwebの設計 - サーバ設計

2010-12-31T17:08:00.006+09:00

nginx、lighttpd、fhttpd、そしてAntiweb3と同じように、Antiweb4は非同期ないしイベントベースないしノンブロッキングなサーバです。つまり、複数のクライアント接続を単一のスレッドで制御します。Antiwebシステムはunixプロセスの集まりです。接続はプロセス間でsendmsg()によって転送されます。これが生じると、ソケットから最初に読まれたデータはそのソケット自身を通じて転送されます。ソケットは常に送信側のプロセスにおいて閉じられます。

ひとつのプロセスの中で多重接続を行なうため、Antiwebはsrc/libantiweb.hに定義されている状態機械データ構造を使います。Antiwebは、level-triggeredモードにおいて、kqueue()またはepoll()のいずれかのステートフルなイベントAPIを必要とします。

32bit linux/CMUCLシステムにおいて、10000の非アクティヴなkeepalive接続は約3Mのユーザ空間メモリを消費した（2つのlispイメージに加えて）。
非アクティヴなkeepalive接続の数は新しい接続において取るに足らない性能影響を持つ。

ファイルの送信には3つのモードがある。すなわち、中、小、大である。

中: これらのファイルはファイルのデータをユーザ空間にコピーするのを避けるためにmmap()される（メモリーマップされる）。データはファイルシステムから直接カーネルのソケットバッファにコピーされる。
小: これらのファイルはユーザ空間バッファに読まれる。というのは、小さなread()は往々にしてmmap()+munmap()より安価だからである。
大: Antiwebは大きなファイルにユーザ空間バッファを使う。これは多数の大きなファイルをクライアントが並列に要求した場合にディスクスラッシングを起こすのを避けるためであり（lighttpdからのアイデアである）、また32bitシステムでアドレス空間を使い切ってしまうのを避けるためでもある。

そいつをスーパーサイズしろ: Antiwebは64bitのoff_t型とlispの桁数無制限の整数をすべてのシステムで使っているので、Antiwebはいかなる容量のファイルでも扱うことができる。また、3つすべての送信モードにおいてダウンロード再開をサポートしている。

Antiwebのデータ構造はパイプラインのために設計されている。Antiwebはベクター型I/O（scatter-gather I/Oとしても知られている）をほとんど全面的に使っている。Antiwebの内部メッセージパッシングプロトコルもパイプラインを使っている。たとえば、ひとつのHTTP接続があって、それが小さなファイルについて2つのリクエストがあり、中くらいのファイルのリクエストが1つ続いてパイプラインされているとき、単一のwritev()システムコールで以下のように対応する。

最初の2つのファイルのためのHTTPヘッダとファイルコンテント
中くらいのファイルのためのHTTPヘッダ
カーネルバッファを満たすまで中くらいのファイルをメモリにマップする

続いて、生成されたログメッセージをすべてハブプロセスにwritev()で書き込む。ハブはログメッセージをロガープロセスに別のwritev()で転送する。最後に、ロガープロセスがメッセージをaxslogファイルに追記する。

ワーカープロセスの接続統計が見たいなら、-statsコマンドを使う。

# antiweb -stats /var/aw/example.conf
...
Keepalive Time: 65 seconds
Total Connections: 41  HTTP requests: 72  Avg reqs/conn: 1.8
File descriptor usage (estimate): 17/32767
Current Connections: 11
Keepalives: 7  Sending files to: 2
Proxy: Sources: 0  Sinks: 0  Idle: 0
Timers: 0  Hub: 1  Unix Connections: 1
Lingering: 0  Zombies: 0
...

ふだんは愛しているけれど、ときどきパイプラインは悪い。Antiwebは特定のレスポンスにおいてパーシステントなHTTP接続を切断する。

4XXおよび5XX HTTPエラー - niktoのようなウェブ脆弱性スキャナがそのリクエストの95%以上をこれらのエラーとするとき、blindになるのを防ぐ。
ディレクトリリスト - パイプラインが再帰的にクロールするのを防ぐ。

接続を完了するとき、Antiwebはソケットと、HTTP/1.1で要求されているようにlingerの書き込みディレクションを切断する。AntiwebはHTTP/0.9およびHTTP/1.0のクライアントを常にgracefullyにデグレードする。Antiwebは第一級のIPv6サポートを持っている。もし、4XXおよび5XXエラーをパイプラインしたいなら、2つの選択肢がある。

Antiwebのrewriteモジュールを使って問題のあるリクエストを実在するファイルへのリクエストに変更する。
Antiwebのfast-filesモジュールを使う。これはメモリキャッシュであって静的なコンテントの加速化、HTTPヘッダの事前生成、ネガティヴキャッシュ、そして404エラーの永続化/パイプライン化をサポートしている。

Antiwebは最初からセキュリティを意識して設計されている。Antiwebの設計中に下された設計上の決定を以下に列挙する。

仮想ホストはプロキシを使わずに権限を分離している。ハブが接続を扱うべきワーカーを決定すると、ハブはワーカープロセスにソケットし、その接続についてそれ以上のことは一切行なわない。ワーカープロセスはハブと異なるUIDsの下で動作する（ワーカープロセスもそれぞれ異なる）。ワーカーはオプションとしてchrootすることがある。
ワーカーはログファイルにアクセスしない。すべてのログメッセージはUnixソケットを通じてハブに送られる。続いて、ハブはそのメッセージをロガープロセスに送る。つまり、ワーカープロセスはそれまでに生成されたログメッセージを盗むことがないし、他のワーカープロセスによって生成されたログメッセージを盗むこともない。同様にハブはそれまでに生成されたログメッセージを盗むことがない。
CGIプロセスはリソース制限によって制約できる。
unicodeをサポートしないLispであっても、Antiwebは内部データならびにファイル名をUTF-8でエンコードする。これにはすべてのコードポイントを最短の表現となるようにし、不正なサロゲートペアがないように検証することが含まれている。(訳者注：本当だろうか？大言壮語ではないか？)
Antiwebプロセスは予期せぬ状態のイベントの後始末や回復をけっして試みない。実行できなかったプロセスは失敗する。失敗しなかったプロセスは終了後に後始末される。

AntiwebにはAnti Webpagesと呼ばれるWebページを構築する実験的な技術が含まれている。これはPerlに触発されたプログラムで、意味のある空白類でページレイアウトを表現したり、HTML/CSS/Javascriptを貼り合わせたりといった機能を持つ。

Antiwebの設計 - Antiwebの新世代

2010-12-31T16:51:00.002+09:00

Antiwebは、Hoytechによって、Common Lisp、C、そしてPerlで書かれたウェブサーバである。Antiwebは「コンセプトの検証」ではないし、「実験的なコード」でもない。Antiwebの中心的な設計は（この設計書に解説しているとおり）次の10年以上にわたって安定して使えることを意図している。
Antiweb4に強い影響を与えたウェブサーバはnginxとlighttpdの2つである。Antiwebを設計するにあたって、これらやその他の優れたサーバを自由に探検させてもらった。もうひとつ影響されたサーバを挙げるなら、fhttpdがそれに挙げられる。

なぜまたウェブサーバか？われわれの意見では、上記のサーバを用いるときの最大の問題として、それらがlispで書かれていない、ということがある。われわれが学んだサーバは、拡張言語で接木されている（nginxにはPerlが、lighttpdにはLuaが採用されている）。Antiwebは違う。他の言語を使うCプログラムとするのではなく、AntiwebはC（とPerl）を使うLispプログラムなのである。

Anti Webpages - ページとレイアウト

2010-12-31T08:50:00.002+09:00

Anti Webpageは.awpで終わるファイルである。ほとんどすべてのAntiwebのファイル同様、.awpファイルはconfsである。各.awpファイルはあなたのウェブサイトの.awp/ディレクトリへのマップである。このディレクトリには複数のページを持つことができ、それぞれはxconfで示される。以下に、1つのページxconfを持つ、簡単な.awpファイルを示す。

(page "index.html"
:layout #"
content                        |
"#
:content #"Hello world!"# )

文字列は正規の二重引用符 (") ないし特殊な #" および "# で区切ることができる。この特殊引用符は引用符文字、バックスラッシュなどをエスケープせずに含ませることができる。
:layoutオプションはawpファイルのセグメントを置くためのものである。そこにはバーティカルバー（|) を終端とする行が最低一行必要になる。すべてのバーティカルバーは「並んでいる」べきである。

上記の例では、:contentセグメントがページの真ん中にある。複数のポジションを示すには複数のバーを使う。たとえば以下のコードでは:contentをページの右端に表示するように指示している。

(page "index.html"
:layout #"
               | content |
"#
:content #"Hello world!"#
)

別の書き方もある。位置修正子 locator modifier (@) を使ってセグメントの位置を示すことができる。以下の例は同じ意味を持つ。

(page "index.html"
:layout #"
content@r
"#
:content #"Hello world!"#
)

@rはそのエリアの右に配置することを示す。使用可能な修正子は@r @l @t @b @tl @tr @bl @br である(ただし文字の順序は問題にしない)。やや複雑な例を示そう。

(page "index.html"
:title "Antiweb Manual"

:layout-width 800
:layout #"
logo@r |  |          header@l         |  slogan  |
nav@rt |  |          content@tl                  |
                     footer                    |
"#

:header #"<h1><u>Antiweb Manual</u></h1>"#
)

上記の.awpファイルがレンダリングされると、ひとつのセグメントが表示され (:header) 、残りはNILとなる、というのはまだそれを追加していないからである。レイアウトとは関係ない特殊キーワードがある。

:title - このページのHTMLタイトル。
:css - CSSコード。複数の:cssパラメータをおいてよい。すべてHTMLページの上部のCSSブロックに追加される。
:js - Javascriptコード。複数の:jsパラメータをおいてよい。すべてHTMLページの上部のJavascriptブロックに追加される。
:js-end - :jsと同じだが、そのコードはページの上部ではなく、ページの下部のJavascriptブロックに追加される。

Anti Webpages

2010-12-31T08:39:00.002+09:00

Anti Webpagesは、実験的で革新的な、Webコンテンツの新しい生成方法である。Antiwebのサーバ部分は、Antiweb Pagesから切り離されており、より直球である --- Antiwebサーバ自身の成し遂げていることと言えば、可能な限り効率的でセキュアにHTTP 1.1を実装しているということに尽きる。これはちょっとおかしな感じがする。Antiweb Pagesは安定していない、というのは、その実際の仕様がそのうちに変更され得るという意味においてのことである（そう近い話とも考えていないが）。

Anti Webpagesの要点は、静的なHTMLファイルを生成することであり、それもAntiwebによって非常に効率的に生成できることにある。Anti WebpagesはAJAXコールバックとフラットファイルないしBerkeleyDBデータストアをサポートするが、基本的には静的コンテンツまわりを処理することがすべてであり、このマニュアルに記載されているのがすべてである。

CMUCL

2010-11-23T18:41:00.004+09:00

CMUCLを使って、Antiweb環境を構築しようと思う。

SBCLを使わずにCMUCLを使うのは、Doug Hoyteに敬意を払ってのことである（ミーハー）。

日本語を使う場合、SBCLの方が何かと便利なのであるが、SLIMEを使わないことを決めたので（これもDougへのオマージュ）、表面的な便利さは捨てて、ハードコアにCMUCLを使ってみることにしたのである。

おいらがGMOから借りているVirtual Private Serverは、すでにUbuntu Serverに入れ替えてある。

だから、Ubuntu Serverを自宅PC（恥ずかしながらWindows Vista 64bitである）のVirtual BoxにUbuntu Serverを入れて、そこで環境構築を練習しよう。

---

む？ 64bitダメなの？

James - ユーザの追加

2010-10-10T20:11:00.002+09:00

ユーザアカウントはサービスを横断して共有される。共通ユーザレポジトリはJamesサービスを横断して共有される。つまり、POP3メールアカウントを作成し、パスワードを設定すれば、同じアカウントがSMTPおよびNNTPの認証にも使えるということである。

アカウントを追加する前に

Jamesでは、ユーザアカウントはリモートマネージャを通じて作成される。だから、インストールが完了したら、まずリモートマネージャを設定することが、ユーザ追加の最初のステップとなる。リモートマネージャの設定についてはここを参照のこと。少なくとも1つの管理者アカウントを設定し、リモートマネージャを有効にすることが必要である。

また、ユーザを追加する前に、ユーザレポジトリの設定を正しく行なうことも必要だ。もしユーザを追加した後でレポジトリタイプをファイルからデータベースに変更すると、ユーザデータを失うことになる。これらの値の取り扱いには注意して欲しい。

これを完了させたら、Jamesを再起動して設定変更を稼働中のシステムに確実に反映させること。これでようやくユーザアカウントを作成できる準備が整った。

ひとたびJamesが起動してリスニングを始めると、ユーザの追加はきわめてシンプルである。

リモートマネージャがリスニングしているホストの当該ポートにtelnetする。コマンドラインのtelnetクライアントでは、一般に「telnet 」と打鍵する。にはJamesのホスト名を、にはJamesのconfig.xmlに指定したリモートマネージャのポートを指定する。
管理者のユーザIDとパスワードのためにプロンプトが出るので、Jamesのconfig.xmlに指定した値を入力する。
ログインしたら、「adduser 」と打鍵する。にはユーザ名を、にはそのアカウントのパスワードを指定する。ユーザ名には完全なemailアドレスを指定するべきではないことに注意。むしろ、すべてのemailアドレスは@の形式(にはブロックに指定した値のいずれかを指定する)がこのアカウントにデフォルトで配送されるものとして使われる。Mailetはこのデフォルトの振る舞いを変更できる。
作成したいユーザすべてについてステップ3を繰り返す。

以上です。ユーザアカウントは作成され、すべてのJamesサービスで使用可能となります。

James - グローバルサーバ設定

2010-10-10T19:44:00.004+09:00

ひとつのコンポーネントに落とし込むことのできないグローバルな設定ブロックがいくつかあります。それらはサーバを横断してグローバルな影響を与えます。いくつかのブロックは非常に重要であり、一方で多くの場合無視されるものもありますが、もっとも洗練されたサーバ管理者にとっては重要なものです。

Jamesブロック

この設定ブロックはJamesタグで定義されます。すべての管理者はこのブロックをインストール時に調整する必要があります。属性はありませんが、いくつかの子があり、すべて必須です。

postmaster - この要素の中身はpostmasterのメールアドレスです。このアドレスはJamesから送信されるすべてのエラーメッセージの送信者アドレスとして使われます。また、postmaster@<サーバ名>宛てのすべてのメッセージは、このメールアドレスにリダイレクトされます。(<サーバ名>には、Jamesが取り扱っているドメイン名のいずれかが入ります。)
usernames - この要素は中身を持ちませんが、三つの必須の真偽値の属性を持ちます。その属性というのは、ignoreCase、enabledAliases、そしてenableForwarding.です。ignoreCaseはemailのユーザ名を大文字小文字を無視するか、無視しないかを決定します。enabledAliasesは、ローカルユーザのエイリアシングを有効にするかどうかを決めます。最後に、enableForwardingはリモートユーザへの転送を有効にするかどうかを決めます。
servernames - この要素はサーバがローカルとして取り扱うメールドメインとIPアドレスを定義します。二つの真偽値の属性 - autodetectおよびautodetectIPがあります。autodetectは、真にすると、サーバに自身のホスト名を確認させて、ローカルメールドメインに追加させます。autodetectIPはサーバに自身のIPアドレスを確認させて、ローカルメールドメインに追加させます。これらの属性の他に、このタグは0個以上のservername子要素を持ちます。

servername - 単一のホスト名またはIPアドレス。サーバがローカルとみなすメールドメインに追加される。

inboxRepository - これは単一の子要素を保持するシンプルなコンテナタグです。

repository - これはメールレポジトリを定義するもので、ローカルに配送されたメールを保持するのに使われる。この要素は中身を持たない。必須属性typeは常に"MAIL"にセットされる。必須属性repositoryURLはレポジトリを指定するのに使う(レポジトリ設定セクションを参照のこと)。

Connectionmanagerブロック

このブロックは一般的な接続管理を成業する。二つの要素がある。

idle-timeout - ミリ秒でクライアントの接続をタイムアウトさせるまでの時間を指定する。値を与えないと、デフォルトで5分、すなわち300000ミリ秒となる。値0はクライアントソケットをタイムアウトさせないことを意味する。
max-connections - max-connectionsパラメータはこの接続マネージャが許容する最大の同時接続数のデフォルトを指定する。この値は個々のサービスによって上書きできる。値を与えないと、デフォルトで30になる。値0は接続マネージャに上限を与えないことを意味するが、他のコンポーネントによるリソースの制限(たとえば最大スレッド数)が接続を開く数を制限することにはなる。

Objectstorageブロック。

低レベルのファイルレポジトリからファイルへの写像を制御するブロック。修正する必要はない。

Socketmanagerブロック

このブロックはJames内部で利用可能なソケットのタイプを制御する。SSLを有効にするのでなければ、このブロックを修正する必要はない。TLSを使う場合には修正の必要があるので、TLSの使用セクションを参照のこと。

Threadmanagerブロック

このブロックはJames内部で利用可能なスレッドプールを制御する。エキスパートの管理者だけがこの設定を修正すべきである。

Twitterクライアントを作ってみる

2010-07-23T07:02:00.002+09:00

Twitterクライアントを作ってみることにした。

Javaで、Maven2とNetBeansを使い、TDDで。

テーマは以下のとおり。

1. Javaの道具に慣れる(今でも普通に仕事をしているけど、いまだにJavaに魅力を感じていないので)。

2. Twitter APIに親しむ(そのうちにTwitter APIを使った仕事がありそうだし)。

単にTwitterクライアントを作るだけなら、Rubyあたりがもっとも手っ取り早い。

Common Lisp（Emacs + SLIMEないしLispWorks)という手もあるね。

でも、それは会社の仕事にはつながっていかないからなあ。

SKKSERV on Ubuntu

2009-10-21T23:17:00.001+09:00

UbuntuでSKKを使いたい場合の情報はネット上にほとんどない。

なんでだろう？　と思ったら、ddskkとdbskkd-cdbをパッケージマネージャからインストールして、inetdを再起動するだけで良いからだった。

ただし、inetdのことは少しメモしておく価値があると思う。Ubuntuのデフォルトのinetdはopenbsd-inetdなので、起動スクリプトも/etc/init.d/openbsd-inetdである。/etc/init.d/inetdが見当たらないので、少し戸惑ってしまった。

J2EE復習

2009-10-04T23:57:00.003+09:00

部下に教える必要があり、J2EEを復習することに。

で、まずはTomcatのことなんだけど。

うちの会社ではTomcatが標準として採用されている（一応、断っておくと、非標準のサーブレットコンテナを採用することは禁止されていない。単に、標準的にサポートされているのがTomcatだということだ）。

Tomcatと同じようなサーブレットコンテナとしては、まずJettyが思いつく。他にはWebLogic、WebSphere、Resinなどがあるようだ。

JettyはTomcatと比較して軽量なサーブレットコンテナとして定評があるようだ。2009年10月4日現在で比較すると、Tomcat 6.xがServlet 2.5/JSP 2.1をサポートしており、最新リリースは6.0.20、Jetty 6.xがServlet 2.5/JSP 2.0をサポートしており、JSP 2.1をサポートしているJetty 7.xはRCである。Jettyは今のところ、6.1.21が最新安定版ということになるようだ。

WebLogicやWebSphereは、その開発環境や運用ツールも込みで選択されるものだから、直接の比較対象にはならない。

Resinはどうか？ ResinはNTTデータがサポートを提供しているくらいであるから、エンタープライズ向けに十分の実績があると思われる。評判によれば非常に高速で安定しているらしい。現状、4.0.1が有償版となっており、3.1.9がGPLで配布されている。まあ、有償版といっても、1CPUあたり$699というから、ビジネスで使う分にはそう高価なものではない。

J2EEを選択する理由というのは、一般に、性能云々より、信頼性や保守性が重要な要求としてあり、その上で性能が問題となったときのスケーラビリティにしかるべき選択肢があること、というのが動機となる。とにかく実行時性能を追求するようなケースでJ2EEを選択するということはさほどない（もちろんJ2EEで高速なWebアプリケーションを追求することは可能であるが、大人数で開発するJ2EEアプリケーションはしばしば低速である）。

だから、メジャーであるという理由でTomcatを選ぶのは道理なのである。だが、一方でJettyやResinにも十分な実績があり、その原因にTomcatの遅さ、不安定さというものがあるのも事実だ。

とりあえずJettyとResinはどちらも使えるようにしておこう。

Apacheのログ解析

2008-10-04T20:55:00.002+09:00

手垢のついたテーマではあるが、ここ2年ほど色々痛い目にあってきたので、ここいらでその経験を活かしたソリューションに仕上げたい。

まず、注意しなければならないのはメモリとCPUを節約しなければならないということだ。アクセスが増えてきたにも関わらず、予算の関係でサーバを増強できないということは、ままある。だいいち、お金があるなら、RTmetricsのようなアプライアンスを導入できるし、その方が良い。予算がない場合が問題なのだ。

WebサーバとDBサーバを1台のサーバ機が兼任しているような環境で、しかもアクセスの増加にあえいでいるような局面でメモリとCPUを贅沢に使うわけにはいかない。だからRubyは選択肢から外さないといけない。なにしろRubyは遅いから。

C/C++という選択も駄目だ。サーバ機がどんなOSで動いているかわからない。多数のサーバOSをサポートするのはできないことではないが、検証環境を揃えるだけの予算がないし、そこまで性能が必要なわけでもない。

Javaは悪くない選択だ。まずは順当というところだろう。たいていのOSでJavaは稼動しているし、パフォーマンスも悪くない。

Objective CamlとCommon Lispも有力な候補だ。どちらもたいていのサーバOSで稼動するし、ネイティブコードにコンパイルできる。DBとの連携にも支障がない。

ほかにも候補はあるが、この3つの言語でそれぞれに実装してみよう。

いろいろひどい目にあった

2008-10-04T17:48:00.001+09:00

腐らず再開しよう。

NetBeansのRubyサポート

2008-09-21T09:06:00.001+09:00

うわさには聞いていたが、かなり賢い。
Rubyのコードを解釈して補完してくれたりするのだが、Rubyの構文は人間には優しいがコンピュータには厄介な代物なので、よくやったなあと感心する。
これでIDEがないとプログラミングできないタイプの人もRailsに来るんじゃないかな。

# 本当はそういう奴はプログラミングの世界に来るべきじゃないんだが。

Blogged with the Flock Browser

NetBeans+JRuby+Rails

2008-09-21T08:37:00.002+09:00

何気にNetBeansのRubyサポートはいい。
Glassfishの上でJRuby on Railsがさくっと動く。今はWEBrickベースなようだが、Glashfishを前提にした本番環境が出てくるだろうね。期待しよう。

Common Lispの美点

2008-09-20T23:22:00.003+09:00

t2ruさんのCommon Lispの美点を読んで。

あえて付け加えるなら、最適化のための汚いコードをマクロの背後に隠すことができる点も強みとして加えてもいいかなあ。
現実のアプリケーションでは、いったん出来上がったコードに最適化のためのコードやアドホックな修正のためのコードが追加されることが多い。そうすると、普通の言語ではどんどん本来の処理が見えにくくなってしまう。その点、Common Lispなら大丈夫だ。

Objective Camlの使いどころ

2008-09-20T22:00:00.003+09:00

カリー化がわかってみると、Objective Camlは良さげに思えてきた。
しかし、実際に何に使おうと思案してみると、意外に使いどころがない。

いや、どんな応用に使っても良いんだろうとは思う。
だが、僕にとっては速度を気にしないならRubyがfirst choiceで、速度が重要なのであればCommon Lispがfirst choiceになっている。そこに割って入るには、相応に理由付けが必要だ。

Ocamlのストロングポイントは、静的型付けの安全で効率的な実行可能ファイルを（Javaあたりなどと比べて）より短いコードで書けるところにあるだろう。
静的型付けという点を除くと、だいたいCommon Lispの方が勝る。特にコードが短くなる点と表現の自由度という点では勝負にならない。
だから、あえてOcamlを使うからには、プログラムの正しさをコンパイラで確認したいというニーズが必要だ。つまり、性能と正確さが要求されるケースだ。

その要求が成立するには、仕様をフォーマルに記述しうる状況が必要だ。RubyやCommon Lispには柔軟性があるから、仕様がフィックスしていない案件で力を発揮する。僕の仕事では、仕様がフィックスしないことの方が多いのだ。

ここ数日、Apacheのアクセスログを解析する高速なプログラムを書きたいと思っていて、Common Lispでやろうかと思っていたのだが、これこそOcamlの出番のように思われる。すでに運用中のプログラムがあるので、仕様はもう固まっているからだ。