Apacheモジュールのmod-spdyを入れてみました。
SPDYは、HTTPを拡張して単一のセッションで複数リクエストを送受信することができるプロトコルです。
利用にはHTTPS通信可能な環境が必要です。

インストールはRPMが配布されているため、それを使うと楽です。

mod_spdy - Google Developers
https://developers.google.com/speed/spdy/mod_spdy/

yum install at
wget https://dl-ssl.google.com/dl/linux/direct/mod-spdy-beta_current_x86_64.rpm
rpm -U mod-spdy-beta_current_x86_64.rpm

インストールすると、Apacheのconf.dディレクトリに設定ファイルができるので、確認するといいでしょう。

ハマったところは、ApacheのSSLRequireSSLディレクティブを利用していると403が出てしまうことでしょうか。

mod_spdy doesn't work with SSLRequireSSL
http://code.google.com/p/mod-spdy/issues/detail?id=31

ひとまず、SSLRequireSSLディレクティブを外して動作させてみました。

ChromeでSPDY通信が有効になっているか確認する場合は、「chrome://net-internals/#spdy」にアクセスするか、以下のエクステンションを使うのが楽です。

Chrome ウェブストア - SPDY indicator
https://chrome.google.com/webstore/detail/spdy-indicator/mpbpobfflnpcgagjijhmgnchggcjblin
（SPDYの時は、URLのわきに緑色の稲妻のようなマークが出ます。）

パフォーマンスの差は体感できませんでした。実運用しているサービスのテスト環境に入れたため、画像などのリソースが別ドメインにあるとかSPDYがあまり効かない条件がそろっていました。

今のところ実運用する必要性は感じていませんが、注目のプロトコルですので、引き続き、チェックはしたいと思います。

Apache のログを眺めていたら、AB（ApacheBench）のアクセスは HTTP 1.0 クライアントとして認識されているようです。このため、AB では、コンテンツ圧縮など HTTP 1.1 を前提にした処理は実行されない可能性があるため、正確には速度を計測できないかも・・・。（少なくとも、AB からのアクセスでは、mod_deflate は走っていませんでした。）

これ・・・私の勘違いですかね？？？

Kodougu のサーバは回線がしょぼい（10Mbps を数台で共有している）ので、結構重要な気がしているのですが・・・。

私は Kodougu について語るとき、いつも「重い、遅い」と言っているのですが、ベンチマークをとったことはなかったので、手始めに AB（Apache に付属するベンチマークソフト）を使って速度を計測してみることにしました。

実行したコマンド

ab -n 100 -c 10 http://www.kodougu.net/rendering/diagram/1

計測したのは一番重くなると思われるモデリングツールを表示するページで、10 のコネクションで、合計 100 リクエストを送ることを試してみました。（もっとも、このベンチマークは、あくまでリクエストを送ってレスポンスを返すまでの時間を計測するものなので、たとえば、script タグで関連付けた外部 JavaScript ファイルの DL 時間などは計測できない・・・と思います。今は敢えてその辺を無視しています。）

ベンチマーク結果

Benchmarking www.kodougu.net (be patient).....done

Server Software:        Mongrel
Server Hostname:        www.kodougu.net
Server Port:            80

Document Path:          /rendering/diagram/1
Document Length:        24522 bytes

Concurrency Level:      10
Time taken for tests:   22.140625 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2479000 bytes
HTML transferred:       2452200 bytes
Requests per second:    4.52 [#/sec] (mean)
Time per request:       2214.063 [ms] (mean)
Time per request:       221.406 [ms] (mean, across all concurrent requests)
Transfer rate:          109.30 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       15   21   8.1     15      46
Processing:   516 2145 2189.3   1390   11765
Waiting:      421 2025 2163.7   1281   11640
Total:        531 2166 2188.7   1421   11796

Percentage of the requests served within a certain time (ms)
  50%   1421
  66%   2046
  75%   2453
  80%   2671
  90%   5453
  95%   7062
  98%  10031
  99%  11796
 100%  11796 (longest request)

サーバは Mongrel となっていますが、間に Apache Proxy が挟まっています。秒間 4.52 リクエストを処理することができるようです。これは、あくまで Web にあげているバージョンで、ローカルで動作させている最新版はさらに重くなっていて、この半分くらいの性能しか出ません。まだ分析していないので、回線、Web アプリ（Rails）、DB（MySQL）のどれがボトルネックになっているのかはわかりません。

まあ、ユーザが少ないうちは、この程度の処理能力でも問題ありません。でも、100 ユーザくらいが同時に使ったら、図を表示するだけで何十秒も待たされることになり、現実的に使えるものではなくなってしまいます。現在は、サーバは一台（CPU:Core2Duo/Mem:1GB）なので、サーバ台数を増やしていくという選択肢もありますが、アプリケーションだけでも 10 倍くらいは改善しないと使い物になりませんね。

機能拡張が落ち着いたら、パフォーマンス改善をしないとなー・・・。

もう朝が近いな・・・。

Kodougu を mod_proxy_balancer でロードバランスしたのですが、Ajax のレスポンスが 10 秒以上待たないと返ってこないという問題に遭遇してしまいました。具体的には、ブラウザ（FireFox）上でモデル要素を動かすと、Ajax リクエストを送信するのですが、これのレスポンスが 10 秒以上たたないと返ってこないという現象です。Apache の httpd.conf をいじって KeepAlive を外したら速くなったのですが、どうも腑に落ちません。

昔、IE では KeepAlive 関係でバグがあってレスポンスが返ってこないというのはあったようですが、今回は FireFox なのでちょっとそれはなさそうな予感がしています。

以下のバグが少し関係ありそうなのですが、効果がないと書いている対処法が、私のケースでは効果があったので別問題でしょうか。時間のあるときに Apache の bugzilla をあさってみますかね。やれやれ・・・。

Bug 37770 - proxy: error reading status line from remote server (null) | Apache | Bugs
http://www.gossamer-threads.com/lists/apache/bugs/314332

■ 追記（2007/3/4 13:24）
上記の Bug 37770 に関係があるかと思い、以下の記述にしたがって httpd.conf を修正してみました（つまり、KeepAlive を On にして、以下の記述を追加した）が、効果はありませんでした。うーん・・・。

mod_proxy - Apache HTTP サーバより：

[code:

SetEnv force-proxy-request-1.0 1

SetEnv proxy-nokeepalive 1]

当面は KeepAlive Off でいくことにします。しばらくはこういった問題がシビアになるほどアクセスが集中するとも思えないので。

○ 問題の整理
Apache（mod_proxy, mod_proxy_balancer）をフロント、Mongrel（Rails）をクラスタリングしてバックエンドに配置した状態で、ブラウザ（FireFox）上でページ遷移のない Ajax を多用した操作を行うと、Ajax レスポンスが返ってくるまで KeepAliveTimeout + サーバの処理時間程度の時間がかかってしまう。（私の環境では、KeepAliveTimeout は 15 に設定しているので、15 秒以上待たされる。）
しかし、ページ遷移のある操作は問題なく動作します。

今日は、Kodougu 公開に向けて、Apache2.2 で mod_proxy_balancer を使ってロードバランスを実現させるということをしていました。つまり、フロントエンドを Apache（mod_proxy, mod_proxy_balancer）、バックエンドは Mongrel という Rails の世界では割と一般的な構成にしました。役割としては、Apache がロードバランスして、Mongrel がリクエストを処理します。Mongrel とは Ruby で書かれた Web サーバで、Rails アプリを動作させることに適しています。

なぜこのようなことをしているのかというと、理由は二つあります。ひとつはパフォーマンスとスケーラビリティに関係するものです。Mongrel は Rails アプリを動作させるには非常によい Web サーバ（Rails と相性がよくて高パフォーマンス）です。しかし、Apache と同じく 1 プロセス 1 コネクションであるため、クライアント（ブラウザ）に直接接続させてしまうと、大量のリクエストが発生したときに（Kodougu では大量のリクエストが発生する）、Web サーバがビジーになって、リクエストを受け付けるまでラグが発生する可能性があります。そこで、複数の Mongrel プロセスを起動して負荷を分散します。Mongrel はロードバランスはしてくれないので、Apache にロードバランスさせているというわけです。
もうひとつの理由は、Mongrel は Rails に特化した Web サーバなので、フロントには別のサーバをおいておきたいという思いがあります。そこで、普段使い慣れている（＋ロードバランス機能を持った）Apache をフロントに置き、Mongrel をバックに配置しました。

さて、設定は楽勝なのですが、mod_proxy_balancer で一点はまりました。mod_proxy_balancer を使うために httpd.conf には以下のような記述を追加します。（実際にはもっとたくさんのバランサメンバがいます。）

ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
<Proxy balancer://mycluster/>
  BalancerMember http://127.0.0.1:3000 loadfactor=20
  BalancerMember http://127.0.0.1:3001 loadfactor=20
</Proxy>

balancer://mycluster/ の最後のスラッシュ（/）を書かなかったがために、ルート以外の URL にアクセスしたときにパーミッションエラーになってしまいました。
# これで何時間もはまってました。。。

気をつけませう。。。orz