Keepalive関連ディレクティブの調整

Apache Http Server (記事作成時バージョン2.2.3)のKeepalive関連ディレクティブの調整(チューニングとまでは行きませんが)を行いたいと思います。 Keepalive関連ディレクティブとは次の3つです。

Keepalive ・・・ On/Off、Keepaliveを有効にするしないかの指定 MaxKeepAliveRequests ・・・ 接続が開始されてから切断するまでに受け付ける最大リクエスト数の指定 KeepAliveTimeout ・・・ 接続しているセッションからのリクエストが途絶えてから、切断するまでの待ち時間の指定

よくよく考えると、当然のようにkeepaliveを「On」にしがちですが、もう少し有効性やより効果的な設定を考えてみる必要があると思います。

1つのWebページを表示するためには、そのWebページのhtmlファイルとそこに表示する画像ファイルやCSSファイルなどを別途リクエストして、サーバから送ってもらう必要があります。それらのファイルが多い場合には、1つのWebページを表示するために、htmlファイル以外に数多くのリクエストを行うことになります。ちなみに、画像は想像以上に多く使っているものです。アイコンやら、ちょっとした枠線、背景画像などよく考えるとみんな画像を使っています。

その際に、Keepaliveを無効にしていると、ファイル一つ一つについて、接続と切断を繰り返さなくてはならなくなります。 Keepaliveを有効にしていると、例え1つのWebページの表示に複数ファイルをダウンロードする必要があるとしても、1つの接続内ですべてのファイル処理を完了させることができるようになります。

ただ、動的htmlファイルの場合は、phpやjavaなどのスクリプト(プログラム)によって、基本的に1つのhtmlファイルとして生成されていると思われます。各種スクリプトを別ファイルではなく、インライン編集するケースも多いと思います。もちろん、動的htmlでも前述の画像ファイルは相応に存在するわけで、リクエストの多少は大きく変わらないかも知れません。

問題は、動的htmlファイルの生成では、

静的htmlファイルの送信よりもサーバ負荷が掛かるということ 比較的大きなファイルになるケースが多いということ

などを考えると、動的htmlファイルの生成~送信の処理を早く終わらせ、接続を切る、というのがベターだと考えます。

このようなことから、私の考えとしては、大規模Webサイトであれば、Webサーバを動的ファイル用と静的ファイル用に分割構成にして(バーチャルホストを分割する方法でも良い)、それぞれ次のように設定を分けるのが良いのではないかと考えます。

動的ファイル ⇒ Keepalive Off 静的ファイル ⇒ Keepalive On ←画像ファイルはこちら

ただし、当サイトは小規模ですので、動的ファイル用と静的ファイル用に分割する必要性まではありませんので、限られたリソースを有効に利用し、かつ無駄を最小限に止める方策を考えたいと思います。

そこで、次のように考えてみました。

1.当サイトの場合、1つのWebページを表示するために、概ね40~50程度の画像ファイルが必要です。 よって、動的に生成された1つのhtmlファイルとそれらの画像ファイル数を合計して、1つの接続でリクエストするファイル数は最大50と考えて良さそうです。それらの一連のリクエスト処理は1つの接続で完了させるようにして(Keepalive ⇒ On)、最大リクエスト数を50程度(MaxKeepAliveRequests ⇒ 50)にすればよい。

2.1つのWebページをサーバが処理するのに概ね0.5~1.0秒、長くても2秒以内に完了していることを別途確認しているので、すべてのファイルリクエスト処理が終わってから、1~2秒程度後にはセッションを切断して良さそうだと判断できます(KeepAliveTimeout ⇒ 2)。

以上のことから、次のような設定で良さそうだと考えられます。

Keepalive On MaxKeepAliveRequests 50 KeepAliveTimeout 2 続きを読む »

mod_pagespeedをやめて、mod_cache、mod_disk_cacheに戻した

Apache HTTP Serverの「高速化」の目的で導入してみたGoogle codeの mod_pagespeed ですが、どうもメモリを食うということが分かってきました。感覚的に、平均500MB程度消費が増えていると判断しています。

恐らくそれが原因でしょうが、逆にWebを含めたサーバのパフォーマンスが悪化するケースが頻発するようになりました。

単純な検証ではありますが、mod_pagespeed を外し、mod_cache に戻すとメモリ使用量の推移とその変化に伴うパフォーマンス悪化が劇的な位に無くなります。 別に、これをもって mod_pagespeed を悪評価するつもりではありませんが、私の環境(WordPressによる動的HTML作成)には不相応だったのかも知れません。

ということで、 mod_pagespeed をやめて、元の mod_cache、mod_disk_cacheの戻しました。

Apache Webサーバーを高速化~mod_pagespeedの導入

Google codeの『mod_pagespeed』を導入してみました。

これまでは、Apache HTTP Server標準のmod_cache、mod_disk_cacheを使用していましたが、ふと『mod_pagespeed』を見つけ、Google codeのサイトを覗いて、試してみる価値があると判断、導入となったわけです。

詳細はGoogle codeの『mod_pagespeed』のページを参照してもらうとして、簡単に導入手順を紹介します。

1.mod_pagespeedの自動最新化のためのレポジトリ導入拒否設定 [root ~]# touch /etc/default/mod-pagespeed

※自動最新化を行うのであれば実行しない。

2.rpmファイルをダウンロード [root ~]# wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.rpm ~経過略~ [root ~]# ll -rw-r–r– 1 root root 749897 1月 28 08:10 mod-pagespeed-beta_current_i386.rpm 3.at のインストール [root ~]# yum install at Loaded plugins: fastestmirror, priorities Loading mirror speeds from cached hostfile * addons: rsync.atworks.co.jp * base: rsync.atworks.co.jp 続きを読む »

proxy_ajp.confを設定する際の注意点

リバースプロキシを使用する際の、proxy_ajp.conf の設定方法をまとめておきます。ProxyPass と ProxyPassReverse について注意点を説明します。

1.1つめのポイントは、「リバースプロキシしたくないURLパスの指示の仕方」。下記のように、パスを指定して、”!”を記述する。

ProxyPass /server-status !

2.2つめのポイントは、「ファイルの上の行からアクセスURLパスが当てはまるか見ていき、当てはまったら、その行での指示に従って動作する」ということ。 下記(例1)のように記述すると、例えば http://www.goofoo.jp/server-status にアクセスしたときにもバックエンドサーバにリバースプロキシされてしまう(先に、/ に当てはまってしまうから)。

(例1)

ProxyPass / ajp://localhost:8009/ ProxyPassReverse / ajp://localhost:8009/ ProxyPass /server-status ! ProxyPass /server-info !

要するに、記述する「順番」が大事。

/server-status や /server-info へのアクセスはバックエンドサーバにリバースプロキシせずに、フロントエンドのhttpサーバで処理したい場合には下記(例2)のように記述する。

(例2)

ProxyPass /server-status ! ProxyPass /server-info ! ProxyPass / ajp://localhost:8009/ ProxyPassReverse / ajp://localhost:8009/