検索
連載

Apacheパフォーマンス・チューニングの実践：ApacheによるWebサーバ構築（16）（2/2 ページ）

前回、ボトルネックになり得るポイントの検討やベンチマークツール「ab」によるパフォーマンス・チェック方法を紹介した。今回はそれらを基に、Apacheのチューニングを行っていく。

[一志達也，TIS株式会社] PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ | 　　　　　　

セッションのチューニング

　ここまでのチューニングは、必要か必要でないかを判断すればよく、手探りで最適な値を探し出すというものではなかった。しかし、これから紹介する「セッションのチューニング」はそうもいかない。ある程度の見通しは立てられても、最適な答えを見つけるのには手間がかかってしまう。

KeepAliveとセッションの切断

　セッションのチューニングの手始めとして、「KeepAlive」について考えることにしよう。KeepAliveはHTTP/1.1から用意されたもので、クライアントとの接続を保持する仕組みである。HTTPは「ステートレス・プロトコル」と呼ばれるとおり、1回の要求（リクエスト）ごとに接続が切断される。しかし、今日では1つのWebページを表示するために複数のファイルが必要となる場合がほとんどなので、1リクエストごとに接続を切っていたのでは効率が悪い。そこで考え出されたのがKeepAliveであり、一度接続したらある条件を満たすまで接続を保持するようになったのである。

　Apacheにおいて、KeepAliveを有効とするか否かを決定するのが「KeepAlive」ディレクティブである。デフォルトは「On」になっているはずだから、そのままであればKeepAliveは有効になっている。便利な仕組みなので基本的には有効に利用したいものなのだが、あまり長期間接続を維持し過ぎると、かえって効率が悪くなるので注意が必要だ。

　なぜ効率が悪くなるのか？ それは、リクエストが終了したら接続を切断できればいいのだが、残念ながらそうした仕組みは備わっていないからである。リクエストが終了したクライアントに対して、いつまでも接続を維持しているとリソースの無駄遣いになってしまう。そのため、適度に接続を切断できるようにしておきたい。

　それを設定するのが、「MaxKeepAliveRequests」ディレクティブと「KeepAliveTimeout」ディレクティブである。MaxKeepAliveRequestsは、接続してから切断するまでに受け付けるリクエストの数、KeepAliveTimeoutは、接続しているセッションからのリクエストが来なくなってから切断するまでの待ち時間を設定する。

　いくら連続してリクエストが来ていたとしても、大量のリクエストを1セッションで受け付けていると、ほかのセッションが割り込むすきがなくなるかもしれない。また、早く接続を切断すると、再び接続を受け入れる際にオーバーヘッドが加わることも考慮しなければならない。難しいところだが、MaxKeepAliveRequests（デフォルトは100）には1ページ当たりの平均的なファイル数＋α程度を設定し、KeepAliveTimeoutにはデフォルト（15秒）よりも小さい値を設定するのがいいだろう。

プロセスの制限と待機プロセス

　Apacheは、1つのプロセスで多数の接続を処理するのではなく、接続ごとにプロセスを1つ作成して動作する。つまり、同時に接続するクライアントが増えれば、それに比例してプロセスも増えるのだ（注）。プロセスが増えれば、メモリやCPUを圧迫するのは当然のことだから、増え過ぎないように注意していると思う。しかし、プロセスを増やすにもCPUパワーと時間を必要とすることは、あまり注意されていないのではないだろうか？

注：これは、Apache 1.3.xまで。Apache 2.0はマルチスレッドで動作するため、1つのプロセスで指定したスレッド分の同時接続を処理できる。


　プロセス数を制限するためのディレクティブが「MaxClients」である。このディレクティブには、同時に接続できるクライアント（厳密にはセッション）の数を指定する。デフォルトは150となっているが、もう少し大きい値を指定するべきだろう。

　この値の調整には、前回紹介したabを使って飽和点を探り出す作業が必要となる。abで同時接続数を上げながら、CPUやメモリの状態、abが示すパフォーマンスの推移を調査する。それに伴ってMaxClientsの値も上げながら、飽和点を探る作業を行うのだ。しかし、飽和点いっぱいに設定するのはお勧めできない。本当に飽和してしまうとサーバがフリーズしたようになってしまい、サービスできるはずのクライアントにもサービスが提供できなくなるからである。少し余裕を持って動作できるくらいがちょうどいいのだ。

　次に調整するのが、待機プロセス（SpareServers）である。先に述べたとおり、プロセスを起動するにも時間がかかるから、いま動作しているプロセスの数よりも余分にプロセスを起動しておく。こうすることで、足りなくなってからプロセスを起動するよりも、大幅にパフォーマンスを改善できるのである。

　待機プロセスには、2つのディレクティブが関係する。「MinSpareServers」ディレクティブ（デフォルトは5）に待機プロセスの最小値を指定し、「MaxSpareServers」ディレクティブ（デフォルトは10）に最大値を指定する。これにより、少なくともMinSpareServersで指定しただけのプロセスが常に待機するが、多くなってもMaxSpareServersで指定した以上にはならない。注意が必要なのは、リクエストを処理しているプロセスは待機プロセスと呼ばない点である。つまり、最大時にはMaxClientsとMaxSpareServersを足した数のプロセスが起動するということだ。

　これらの値の調整は、Webサイトの性質によって変わるので一概に基準を示すわけにはいかない。1つだけいえるのは、MinSpareServersとMaxSpareServersの数値の差をあまり大きくすべきではないということである。いずれにしても、次の接続を待ち受ける「待機」プロセスなのだから、その値はそれほど大きなものにはならないはずだ。

　プロセスの数そのものは上記の3つのディレクティブで指定すればいいのだが、それらとは別にプロセス自体の生存回数を決めるディレクティブがある。それが「MaxRequestsPerChild」ディレクティブである。プロセスは、一度起動すると通常はApacheを停止するまで起動したままになる。プロセスが停止するのは、MaxSpareServersを超えて待機状態になったときだけだ。

　もちろんそれでも構わないのだが、まれに長時間起動したままになっていると、徐々にメモリーリークなどの問題を引き起こすことがある。そこで、一定回数以上リクエストを処理したプロセスは、一度停止させようというのがMaxRequestsPerChildディレクティブの役割だ。このディレクティブは、デフォルトでは「0」（無制限）となっているが、一定回数でプロセスをクリーンアップしたければ特定の数を指定する。サイトのアクセス数にもよるが、100から1000の間くらいで、適当な値を指定するといいだろう。

稼働状況の把握

　チューニングによってどれくらいパフォーマンスが改善したか、abなどで調べるだろう。もちろん、値を変化させながら測定したりもするだろう。しかし、それはあくまでも推定された状況での調査にすぎない。実際の稼働中に、どれくらいの同時アクセスが発生しているのか、プロセスの数はどうなっているのか。そうした実稼働状況を見て、そのときの体感速度などを測ってみなくては、チューニングの成否など分かるはずもない。

mod_statusによるステータス表示

　Apacheにおいてそうしたリアルタイムの稼働状況を調べるには、OSコマンド（psやvmstatなど）のほかに、mod_statusを使うことが考えられる。Apacheのインストール時に、「--enable-module=status」または「--enable-shared=status」とすればmod_statusがインストールされる。すると、httpd.confには次のような行があるはずなので、そのコメントアウトを外して「Allow from ..」に参照を許可するドメインなどを指定する。

#<Location /server-status>
#    SetHandler server-status
#    Order deny,allow
#    Deny from all
#    Allow from .your-domain.com
#</Location>

　設定変更後に「http://ホスト名/server-status」にアクセスすると、稼働状況を示すページが表示される（画面1）。表示されるデータは瞬間的な状況でしかないから、細かな分析はできない。しかし、同時アクセス数など大まかな状況の把握には役立つと思う。まだ使ったことがないのであれば、ぜひ一度試してみていただきたい。

画面1　mod_statusによるステータス画面
画面1　mod_statusによるステータス画面

Web Application Stress Tool

　以上で筆者が知り得る限りのチューニング・ポイントの紹介は終わりだが、まだ懸念事項がある。それは、abによるパフォーマンス測定は、しょせん単一URLへのリクエストでしかない、という点である。

　実際のWebアクセスにおいて、リクエストのすべてが同じURLを指定しているなどあり得ないし、各自が思い思いにページを遷移していくはずだ。完全に現実と同じ状況をシミュレートすることなどできないかもしれないが、もう少し現実に則した測定ができないものだろうか。

　市販のソフトウェアやサービスを利用するのも1つの手段ではあるが、高価である場合が多い。もちろん、価格に見合うだけの測定をしてくれるが、なかなかその導入にまで踏み切れないところだろう。そんな方に試してみてほしいのが、Microsoftが提供する「Web Application Stress Tool」である。このツールは無料で提供されているので気軽に使えると思う。

　このツールは、あらかじめ用意したスクリプトのとおりにWebサーバにリクエストを発行する。スクリプトはプログラムをコーディングするようなものではなく、「Record」と呼ばれる機能で、IEの操作を記録するだけだから簡単だ。パフォーマンス・チューニングの仕上げに、一度使ってみるといいだろう。

チューニングのコツとは？

　具体的なテスト結果などを提示するには至らなかったが、Apacheチューニングの勘所はご理解いただけたと思う。意外にチューニング・ポイントが少なくてがっかりされた方もいるかもしれないが、Webサーバの単純さから考えればこんなものだろうと思う。多くの場合、パフォーマンスに問題が出るのは動的コンテンツだから、無理にApacheでパフォーマンスを改善するよりも、アプリケーションサーバやデータベースサーバのチューニングを行う方が賢明だ。

　重要なことは、バランスよく、少しずつ設定を変えながら様子を見ることだ。あまり急激に変化をつけても、効果が出るかどうか分からないからである。そのうえで、何をやっても望んでいるパフォーマンスと隔たりがあるようなら、性能の悪いプログラムの改良や機器の増強なども検討するべきだろう。

　本連載もこれが最後となった。最後までお付き合いいただいた諸氏に感謝したい。

「ApacheによるWebサーバ構築」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ | 　　　　　　
ページトップに戻る