Apacheパフォーマンス・チューニングのポイント：ApacheによるWebサーバ構築（15）（1/2 ページ）
Apacheをチューニングすることにより、Webサイトのパフォーマンスをより向上させることができる。しかし、その前に何をチューニングすべきなのかを見極める必要がある。
この連載もいよいよ大詰めとなった。長く続けている間にApache 2.0のリリースまで迎えてしまったが、筆者が思い付く限りのことを紹介してきたつもりだ。
最後に残したテーマは、「パフォーマンス・チューニング」である。より少ない資源でより高速なレスポンスを確保するために、パフォーマンス・チューニングは欠かせない。これは、あらゆるソフトウェアに当てはまる。設定が一通りできるようになればApacheを問題なく動作させることが可能だが、それをより効率よく動作させられなくては不十分だ。
本サイトの読者であればよくご存じのことと思うが、パフォーマンスのチューニングは非常に奥深いものである。語り尽くすことなどできないが、皆さんの一助となれば幸いである。
チューニングへのアプローチ
パフォーマンス・チューニングという言葉に敏感な人は多い。同じ処理であれば、できる限り短時間で終わる方がよいということは、共通認識たり得るからだろう。しかし、そのアプローチは実にさまざまであり、そう簡単にはできない。
コラム 非論理的思考
周囲を見回してみると、暗やみの中を手探りで進むことを楽しんでいる人もいるように感じるときがある。論理的に思考することなく、ブラックボックス化されたソフトウェアの内部を想像し、想像のうえで議論しながら試行錯誤していないだろうか？
筆者にもそうした時期はあったが、分からないものは分からないのだ。
論理的に考えれば、パフォーマンスのチューニングといっても、できることは限られている。人間にとってはいくつもの意味を持った処理であっても、コンピュータにしてみれば、どれも「入出力を伴った計算」にすぎないのだ。つまり、次の4つの要素で構成された一連の作業でしかない。
- CPUでの計算
- ディスクの読み書き
- メモリの読み書き
- 周辺機器とのやりとり（ネットワークやプリンタなど）
要は、それを「いかに速く終わらせるか」というだけの話である。
Apacheのチューニングポイント
コンピュータが行う作業が明確になれば、後は1つ1つをいかに短時間で終らせるかを考えればいい。
CPUの計算時間を短縮する方法は、2つしか存在しないと考えられる。「CPUを高性能なものに取り換える」か「プログラムコードの効率を上げる」かである。
もちろん、Apacheはオープンソースのソフトウェアだから、プログラムコードを書き換えて効率を改善することはできる。しかし、それはあまり現実的ではないだろう。なぜなら、自分で作ったプログラムと違って、ボトルネックや改善点を見つけるのは容易ではないからである。人によっては難しくないのかもしれないが、ここでは現実的ではないとして除外することにする。
CPUに続いて考えるべきはディスクの読み書き時間の短縮だが、これも2つの選択肢が存在する。「ディスクを高性能なものに取り換える」か「ディスクの読み書きを少なくするようにプログラムコードを改良する」かである。
これも先ほどのCPUの場合と同じで、Apacheのプログラムコードを書き換えるのは現実的でない。もう想像に難くないと思うが、メモリの読み書きの時間を短縮することについても、同様の結論が導き出されてしまう。
そうなると、「Apacheでは何もチューニングできないのか」と思われるかもしれないが、実はもう1つのアプローチが存在する。それは、「いかに多数の同時接続を処理するか」である。ご存じのとおり、Apacheは単独のリクエストを順次処理するのではなく、同時に多数のリクエストを受け入れる性質のソフトウェアである。これは、データベース・サーバでOLTPを行うのに似ている。1つ1つの処理速度を向上させるのと同様に、同時に多数のリクエストを処理できるようにすることが重要となるのである。
Webシステム固有の問題
Apache単独で見れば、前述したチューニング・ポイントしかない。しかし、WebではApache以外の要素も関係してくる。クライアント（Webブラウザ）が処理を要求し、サーバ（Apache）がそれにこたえ、クライアントにWebページとして表示するまでが一連の処理といえるからだ。細かく挙げるとキリがないが、それを完了するまでには大まかに次のような時間が必要となる。
- サーバ側（Apache＋α）の処理時間
- ネットワークの通信時間
- クライアント側（Webブラウザ）の処理時間
ここで、サーバ側を「Apache＋α」としたのには理由がある。一般的なWebサーバであっても、昨今は動的なWebページ、すなわちプログラムの実行結果に基づくページを扱うものが多い。この場合、Apache単体の処理時間に加えて、ページを作成するプログラムやアプリケーションサーバの処理時間を必要とする。Apache単体でできるチューニングは限られていても、これらのプログラムの処理時間を短縮するために、CPUの計算時間やディスクの読み書きの時間を短縮する努力は意味があるだろう。
クライアント側では、HTMLのレンダリングという処理が行われる。Webブラウザは、HTMLを受信するとその内容を解析して表示（レンダリング）する。そのHTMLファイル以外に画像や動画などのファイルが必要であれば、それも別途受信して表示する必要があるのだ。この時間には多くの場合、Apacheがファイルを送り返す時間よりも短縮の余地が残されているものである。きれいにデザインされた見栄えのいいページ作りと、Webブラウザのレンダリング時間の短縮。この相反する問題を解決するのは容易ではないが、シンプルで短いHTMLは、それだけネットワークの通信時間を短縮することにもつながる。
HTMLのパフォーマンスを改善するなら、Webページを構成するファイルをすべてローカルコンピュータに準備し、Webブラウザで開いてみればいい。それにかかる時間が、Webサーバやネットワーク以外にかかっている、レンダリングの時間と考えられる（編注）。あまりにも遅いようなら、それを改善する努力をするべきだろう。
編注：もちろん、ここにはローカルディスクの読み込み時間も含まれる。
ネットワークの通信時間の短縮についても考えたいところだが、これは閉鎖されたネットワーク（イントラネット）でしか意味を成さない。インターネットにおいてネットワークのパフォーマンスを上げようとしても、手の届かない（自分の管理範囲でない）問題になるからである。もちろん、サイト内のサーバ間やインターネットの出口（専用線の手前）までのパフォーマンスが悪ければチューニングするべきだが、できることは限られている。
とにもかくにも、リクエストを発行してからWebブラウザにページが表示されるまでの時間が遅いと感じるならば、Apacheだけでなくこれらのポイントにも着目するべきである。
Copyright © ITmedia, Inc. All Rights Reserved.