PolzerシェアWebアプリケーションおよびサーバの高負荷時の挙動を確認する方法の1つが、擬似的に負荷をかけてテストを行うことだ。ここでは、そうしたテストを実施するフリーソフトウェアをいくつか試し、それぞれがどんなタイプのサイトに適しているかを調べた。JMeterの5つが候補として残る。Rubio氏が取り上げているので、ここでは詳しく説明しない。最後のまとめでほかのツールと共に簡単に触れている。curl-loadercurl-loaderは、「SpirentのAvalancheやIXIAのIxLoadの代替として使える強力かつ柔軟なオープンソースのテストソリューションの提供」を目的としている。完成度と柔軟性の高いcURLライブラリを利用して、要求や認証、セッションの処理を行う。curl-loaderのビルド方法は単純明快で、パッケージをダウンロードし、展開して、展開先のディレクトリでコードのmakeを行うだけだ。<limits.h>」という行を追加する必要があった。最近のglibcヘッダファイルの変更が原因だろう。curl-loaderをコンパイルして実行するには、OpenSSLのライブラリとヘッダファイルのインストールも必要になる。テストを始めるには設定が必要だ。curl-loaderの設定は2か所で行う。1つは、具体的なシナリオを決めるパラメータを記述する設定ファイルである。書式は簡単で、変数に値を代入する「VAR=VALUE」という形の式を1行ずつ並べる。非常にわかりやすいサンプルが、ソースツリーの「conf-examples」ディレクトリにいくつか用意されている。curl-loaderでは、複数のIPアドレスを使って、別々のクライアントから要求が来る状況を再現できる。そのため、INTERFACE、CLIENTS_NUM_MAX、NETMASK、IP_ADDR_MIN、IP_ADDR_MAXの各値を各自のネットワーク環境に合わせて調整する必要がある。同時接続可能な最大クライアント数は、指定するIPアドレスの範囲によって決まる。1つの設定の場となるのが、curl-loaderを実行するコマンドラインインタフェースだ。必須となる「-f」引数には、テストに使うシナリオファイルの場所を指定する。その他の引数は、実施するテストの微調整に用いる。curl-loaderのデフォルト設定では、要求の発行がシングルスレッドで行われる。システムリソースの節約とパフォーマンスの向上には悪くない設定だが、マルチコアCPUのマシンであれば「-t」オプションを使って、利用するコア数に応じてスレッドを追加するとよいだろう。テストの結果は、サマリ情報が画面上で定期的に更新されるほか、詳細な情報がログファイルに記録される。拡張子が「.log」のファイルには発生したエラーの情報が、「.ctx」ファイルにはクライアント別の統計情報が、「.txt」ファイルには時系列の統計情報がそれぞれ書き込まれる。Pythonで書かれた、curl-loaderの類似ツールとしてPylotがある。こちらはGUIを備え、設定ファイルがXML形式になる。Laboratoriesが開発した、シングルスレッドで動作するコマンドラインの負荷テストツールだ。httperfでは、設定のほとんどをコマンドライン引数で行う。設定ファイルは、セッションのシナリオを記述するための補助的な役割を担う。以下は、接続数を5,000、各接続が発行を試みる要求数を50とした場合の実行例である。--num-calls=50最初の出力行には、コマンドラインで指定されずにデフォルト値が割り当てられた引数も含め、コマンドの引数群が次のような完全な形で表示される。--num-calls=50curl-loaderと違って、httperfは実施しているテストの経過表示の更新も、詳細なログの記録も行わない。テスト終了時に結果のサマリが表示されるだけである。デバッグ用のスイッチを使えば実行中のテストの内容を把握できるが、このスイッチを有効にするにはコンパイルをやり直す必要がある。httperfで個人的に気に入っているのは、すべてのパラメータをコマンドラインから指定できる点だ。負荷テストの条件をその場でいろいろと変えながら試し、条件が決まったらそのパラメータをシェルスクリプトに記述すればよい。すれば、さまざまなテストを逐次的に、あるいは並行して実施するのも簡単だ。コマンドライン引数の解釈の部分に詰めの甘さが見られる。対象URIのサーバとパスの部分を別々に指定する必要はない。パスの部分の指定に「--uri」というオプションを使っているが、URIにはサーバ名が含まれることもあるので、このオプション名は適切とはいえない。httperfと同じスタイルでもう少しシンプルなツールがよければ、http_loadを試すとよい。Siegeほとんどすべての設定をコマンドライン引数で行えるという点で、Siegeはhttperfに似ている。Siegeではマルチスレッド処理によって要求を送信するほか、低レベルのオプションがhttperfよりも少なく、URLのリストを対象としたテストを実施できる。各オプションにわかりやすい名前が付いているので、httperfより使いやすい。デフォルトのパラメータ設定でSiegeを実行するには、単純に次のようにする。localhostただしこれでは、リストにした複数のURLを対象として、実環境のユーザが引き起こすような不確定性の高い状況でのテストが可能なSiegeの特徴を活かしきれない。Siegeの作者は、URLの収集用にSproxyという支援ツールを提供している。このツールは、インストール後に次の形で実行する。urls.txtすると、実行したターミナルの画面に、収集されたすべてのURLが表示されると共に、それらのURLがurls.txtというファイルに書き込まれる。ブラウザの設定でHTTPプロキシを「localhost:9001」にしたうえで、サイトの閲覧を開始しよう。すると、Siegeで用いるURLの情報がSproxyによって記録される。テスト用のURLが集まったら、次のようにして、テストの実行に移る。--file=urls.txt「--internet」引数を指定すると、Siegeはurls.txt内のURLを(多くのインターネット利用者と同じように)ランダムに使用する。TsungTsungは、URLが列挙されたファイルを用いるところはSiegeに似ているが、ユーザエージェントのランダムな切り替え、疑似的なセッションの生成、動的なデータのフィードバックなど、より高度な機能を備えている。Threads)の利用により、パフォーマンス的にも優れている。Tsungの利用は面倒だ。Siegeやcurl-loader、httperfと違い、コマンドラインからは実行できない。「~/.tsung/tsung.xml」というシナリオファイルを手作業で、あるいはレコーディングモードを使って作成する必要がある。このモードはSiegeのSproxyに似ており、次の手順で実行する。recorder」でTsungによるプロキシの記録を開始し、プロキシサーバを「localhost:8090」にして対象のURLを開く。「~/.tsung」に新しく生成されたセッション記録を開き、シナリオの詳細事項を編集する。編集結果を「~/.tsung/tsung.xml」として保存する。start」でテストを開始する。難しいのは、手順2の設定ファイルの作成だ。Tsungの高度な機能を利用するには、どうしても設定ファイルの書式の理解が必要になる。TsungではPostgreSQLやJabberのサーバに負荷をかけることもできる。まとめここで紹介したツールにはそれぞれ長所と短所がある。すべてに共通しているのは、詳しいドキュメントがあり、容易にインストールできて、動作が安定していることだ。各自の環境に合ったツールを見つけるには、次の順で試すとよいだろう。シンプルなSiegeを使ってみて、そのパフォーマンスと機能に満足できるか確かめる。それでだめなら、もう少し機能が豊富で高速なhttperfを試してみる。複雑なシナリオ設定が必要であれば、最高の機能とパフォーマンスを備えたcurl-loaderやTsungに換えてみる。Tsungのほうは慣れるのに時間がかかるだろう。JMeterしかない。JMeterは機能面でも充実しており、コンテンツの前処理や後処理といった独自の機能も見られる。GUIアプリケーションがよければ、こちらを試すとよい。Polzerは、動的Webサイトの開発を専門としてフリーランスで活動。