Page ｜ 1 ｜ 2 ｜ 3 ｜ 4 ｜ 5 ｜ 6 ｜
実例で学ぶWebシステムのチューニング手法
|
クライアントの性能について
サーバ側に問題がなくても、クライアント側の問題で思うように性能が出ないこともある。
クライアントPCとブラウザ
デザインに凝ったページや、大きなTableがあるページを表示する場合など、WEBシステム側ではなく、クライアントPCやブラウザがボトルネックになる可能性もある。特にデザインに凝ったページを作成したときや、大きなTableを使用する場合に注意が必要である。ブラウザによって画面表示に要する時間はかなり異なる。あるブラウザでは、1秒で表示できるWebページを、別のWebブラウザで表示させると5秒かかるといったことが珍しくない。また、エンドユーザは、システムの開発、検証に用いたマシンよりかなりスペックが劣ったマシンを使用しているかもしれないことを考慮しなければならない。
メジャーなブラウザについて、少し古めのPCでもストレスなく使用可能なページをデザインしなければいけない。
クライアントPCが使用している回線
エンドユーザが、アナログのモデムや携帯電話を介してシステムにアクセスする場合、クライアント側のネットワークの容量がボトルネックになる。ここがボトルネックになる場合は、コンテンツの大きさを小さくすることが最大のポイントとなる。画像ファイルの大きさを小さくする、画像の圧縮率を上げる、htmlの冗長な記述を削るといった対策が考えられる。
開発時はLAN経由でアクセスするため、クライアント側の回線が細い場合のことを見落としがちである。コンテンツの転送に要する時間は、コンテンツの大きさ÷回線速度で容易に算出できる。エンドユーザの使用する回線の容量と、許容できる転送時間から、コンテンツの大きさの上限が決まるので、これを目安に不必要にサイズが多きいコンテンツは作らないようにして欲しい。
ボトルネックの見つけ方
ここでは、実際にどのようにしてボトルネックを見つけていくのかを解説する。まずは機器単位(ネットワーク機器やサーバマシン)で、性能を測定しどこがボトルネックになっているかを見極め、次のその機器のなにがボトルネックになっているかを見極めてゆく。
クライアントPCとブラウザ
WEBシステムの性能は二つの指標、「スループット」と「レスポンスタイム」で評価する。
・スループット＝単位時間あたりにシステムが処理できる処理数
・レスポンスタイム＝ひとつの処理に要する時間
スループットは1秒あたりどれだけブラウザにレスポンスをかえすことができるかをあらわし、レスポンスタイムはブラウザからリクエストを受けてからレスポンスの送信が終わるまでの時間をあらわす。
システムの負荷とスループットレスポンスタイムの間には図5-1のような関係がある。クライアントの数が増えると、それに比例してブラウザからのリクエスト数が増える。ある一定の値までは、レスポンスタイムはほとんど変わらず、スループットはクライアントの数に比例する(図のAの領域)。この領域ではシステムの性能に余裕がある。
ブラウザからのリクエスト数が増えて、ある臨界点を超えると、ブラウザからのリクエストが増えてもスループットは増加せず、レスポンスタイムが増加するようになる(図のBの領域)。この領域では、システムの性能限界点に達している。
レスポンスタイムとスループットはしばしば混同して用いられる。システムの性能が向上すると、図5-2のよう臨界点が矢印の方向に移動し、にスループットが向上、レスポンスタイムともに向上することから、スループットの増加 = レスポンスタイムの向上と捕らえてしまうことによる。スループットの増加 = レスポンスタイムの向上という関係はＢの領域でしか成り立たないことに注意してほしい。
レスポンスタイムの向上を目指してチューニングを行う場合は、問題がAの領域で起きているのか、Bの領域にあるのかが重要である。図Aの領域でのレスポンスタイムが問題ならば、一つ一つのリクエストに対するレスポンスタイムを向上させるチューニングが必要であり、図Bの領域でのレスポンスタイムが問題なのであれば、システムの性能限界をあげるチューニングが必要となる。
図5-1、図5-2は理想的なシステムを想定しているが、実際のシステムの性能を測定してみると、図5-3のような形のグラフが得られることが多い。Aの領域では、クライアントの数に比例してスループットが向上するところは同じだが、臨界点に近づくに従ってスループットの向上が頭打ちになる。また、Bの領域では、スループットがクライアントの数によらず一定なのが理想なのだが、クライアントの数が増えるに従って、スループットが低下し、ついには処理が全く行えない状態になる。このようなシステムは負荷が過大にかかった状態に非常に弱い。
システムがしばしば、Bの領域で稼働するのならば、できるだけ図5-1に近いかたちで動作するようにチューニングをしなければいけない。
WEBサーバ単体の性能の測定
まずはWEBサーバ単体の性能を測定する。図6のようにテスト用のクライアントとWEBサーバのみで試験を行う。ルータや、ファイヤーウォール等のネットワーク機器はテスト用クライアントとサーバの間に入れてはいけない。テスト用クライアントとサーバはクロスケーブルで接続するか、同一のハブに接続する。
WEBサーバには、htmlファイルや、イメージファイル等の静的なコンテンツを置き、テスト用クライアントからこれらのファイルに次々とHTTPのリクエストを出させたときの性能を測定する。テスト用のクライアントには、フリーソフトではJakrtaプロジェクトのJMeter、市販製品ではMercury Interactive社のLoadRunner等の負荷テストツールが使用できる。
テストツールは、コンフィグレーションに一台のPCで複数クライアントからのアクセスをエミュレートすることが可能なので、クライアント数を増加させていったときに、平均レスポンスタイムとスループットを測定し、測定結果から、図5のようなグラフを作成する。また、測定作業時に、クライアントPCと、サーバのCPU利用率、メモリ使用量と、LANのトラフィックの測定も行う。
CPU利用率の測定には、OSがWindow NT/2000であれば、パフォーマンスモニタを、OSがLinuxやUnixの場合は、sar, vmstatコマンドを使用するのが良いだろう。メモリ利用率は、物理メモリの利用率で判断を行う。仮想記憶を使用すれば物理メモリ以上のメモリを使用することも可能なのだが、ページングが頻発し大幅にパフォーマンスが劣化してしまうので、物理メモリに余裕がある状態で運用するのが基本である。物理メモリの利用率をみるのではなく、ページングがどの程度起きているかで、メモリが足りているかを判断しても良い。
LANのトラフィックの測定にはLANアナライザを使用する。ネットワーク系のボトルネックを判断するため、LANアナライザがあると便利である。LANアナライザが用意できない場合は、UNIXのsarコマンドや、WINDOWSのパフォーマンスモニタを使用してLANのトラフィックを測定する。
作成したグラフをみると、クライアント数が少ない間はスループットがクライアント数に比例し、クライアント数が増えるとスループットが頭打ちになるはずである。スループットが頭打ちになったときのスループット値、WEBサーバのCPU使用率、メモリ使用率、LANのトラフィックから、ボトルネックになる箇所と、WEBサーバの性能を判断する。
一通りのデータがそろったら図7のチャートに従って測定データを評価する。
まず、クライアントPCのメモリが不足した場合は、正しいデータ取得できていないので、より多くのメモリを積んだマシンを用意するなどして測定をやりなおす。
また、サーバ側のメモリが不足する場合は、ページングが頻発しWEBサーバは本来の性能が発揮できていないはずなので、より少ないメモリで動作するようにコンフィグレーションを変えて測定をやり直す。WEBサーバに限らず、メモリ不足は大幅なパフォーマンス劣化を引き起こすため、常にメモリに余裕がある状態を保つことは重要である。
次に、WEBサーバのCPU利用率をみる、WEBサーバのCPU利用率がほぼ100%であれば、スループットの測定値がWEBサーバの性能値であると判断する。WEBサーバのCPU利用率に余裕があり、クライアントPCのCPU利用率がほぼ100%になっているならば、クライアントPCの能力不足で、正しい測定が出来ていない。より高性能なクライアントPCを用意して性能を測定してもよいのだが、とりあえずは、WEBサーバは少なくとも測定値の性能を持つと考えて、再測定は行わない。
大抵のシステムでは、アプリケーションサーバかDBサーバがボトルネックになるため、アプリケーションサーバ/DBサーバの性能と比較してWEBサーバがボトルネックにならないことが確認できれば、正確なWEBサーバの性能を測定する必要はない。
また、インターネットに接続するシステムの場合、対インターネットの回線がボトルネックになることも考えられる。測定時のLANトラフィックが、対インターネットの回線容量より大きければ、対インターネットの回線がボトルネックとなるため、WEBサーバは十分な能力をもつと判断する。
WEBサーバ、クライアントPCのCPU利用率、およびLANのトラフィックすべてに余裕がある場合は、WEBサーバのオプションパラメータやOSカーネルパラメータのチューニングによりさらに性能が向上する余地があることを示している。ただし、WEBサーバの性能がボトルネックにならない限り、WEBサーバのチューニングは行わず、WEBサーバは少なくとも測定値の性能を持つと判断する。
SSL使用時のWEBサーバの性能測定
システムがHTTPSを使用し、SSLアクセラレータを使用しないのであれば、SSL使用時のWEBサーバの性能を測定する。HTTPではなくHTTPSを使用することを除けば、測定の方法は SSLを使用しないときのWEBサーバの性能の測定方法と変わらない。
SSLを使用すると猛烈にCPUリソースを消費するため、クライアントPC、サーバのどちらかのCPU利用率が100%になり、そこでスループットが頭打ちになるはずである。サーバのCPU利用率が100%であれば、それがWEBサーバのSSL使用時の性能と考える。クライアントPCのCPU利用率が100%になってしまった場合は、その時のサーバのCPU利用率からサーバの性能を見積もる。たとえば、クライアントPCのCPU利用率が100%の時、サーバのCPU利用率が33%ならば、SSL使用時のサーバの能力は測定値の3倍程度であると考える。
SSLアクセラレータを使用する場合は、クライアントPCのCPUリソースがボトルネックになり、SSL使用時のスループットの見積もりは難しい。とりあえずは、SSLアクセラレータの性能が十分高いと仮定し、SSL使用時でもSSLを使用しないときと同程度の性能が得られると考える。
ネットワーク機器を含めた性能の測定
つぎに、ルータやファイヤーウォールを実運用時と同じ構成に配置し、WEBサーバ単体での性能測定と同様の手順で性能の測定を行う。WEBサーバ単体での測定とほぼ同じ結果が得られれば、ネットワーク機器がボトルネックにはないと判断できる。また、WEBサーバ単体での測定値より低いスループットしか得られないのならば、ネットワーク機器がボトルネックになっていると考えられる。
この段階では、どのネットワーク機器がボトルネックになっているかを調べることはせず、性能値を記録することにとどめ、ネットワーク機器がシステム全体のボトルネックになっていると考えられる状況になったとき改めて、どのネットワーク機器がボトルネックになっているかを調べ対処する。