私が書いた developerWorks の記事、「Web サービスの脆弱性を避けながら Ajax アプリケーションをスピードアップさせる」では、ネットワークのボトルネックの原因として、過剰な帯域幅、頻繁に行われる HTTP リクエスト、そしてメモリー・リークを取り上げました。この記事では、ボトルネックを排除、あるいはその数を減らして Ajax アプリケーションのパフォーマンスを改善する方法を説明します。
この記事では、以下の目的を達成するための便利なパフォーマンス・ツールを紹介します。
- アプリケーションが行う HTTP リクエストの数を減らす
- ディスクの入出力問題を突き止める
- ネットワーク・トラフィックを分析する
- 過剰な呼び出しを発見する
- メモリー使用量を抑える
- その他のパフォーマンス問題を解決する
ここで説明するツールは、オープンソースのツール、Firefox のアドオンという 2 つのカテゴリーに分類できます。
このセクションでは、以下のツールについて説明します。
- Apache Bench: サーバーでの負荷をシミュレートするためのツール
- Tsung: マルチプロトコルの負荷をテストするためのツール
- Bonnie++: ディスクの入出力問題を突き止めるためのツール
- Wireshark: ネットワーク・トラフィックを分析するためのツール
- Comet server application tools: アプリケーション用ツール: 接続の存続期間の延長、並行処理の増加、遅延の短縮、サーバー負荷の削減のために使用するツール
この記事では、JavaScript および HTML コードがすでに最適化されており、過剰な呼び出しや不要なタグ、重複した行が除去されていることを前提とします。このような最適化をまだ行っていない場合は、Firefox でサーバー・パフォーマンスをテストする前に、Dojo Toolkit (Ajax ツールキットの 1 つ) を使用して過剰な呼び出しを排除することをお勧めします (Dojo へのリンク、ならびにこの記事で紹介するその他のツールへのリンクは「参考文献」に記載しています)。
Apache サーバー (または任意の Web サーバー) で負荷をシミュレートする必要がある場合には、標準 Apache HTTPd ディストリビューションに含まれている Apache Bench を利用することができます。このベンチマーク・ツールは Web サーバーに接続し、複数のユーザーをシミュレートします。以下の 3 つのオプションを使用して必要な情報を取得してください。デフォルト設定のままだと、意味のあるベンチマーク結果は得られません。
| オプション | 説明 | デフォルト |
|---|---|---|
| -n requests | サーバーが 1 秒あたりに処理できるリクエスト数を取得します。 | 1 つのリクエストしか行いません。 |
| -c concurrency | パフォーマンスに影響せずに各サーバーが同時に実行できるリクエスト数を取得します。 | 一度に 1 つの HTTP リクエストしか行いません。つまり、並行性はありません。 |
| -t timelimit | ベンチマーク・セッションに費やす秒数 (最大 50000 秒) を設定します。 | 時間制限はありません。 |
上記以外のオプションを使って、送信するリクエスト、プロキシー設定、ユーザー認証、および cookie を細かく制御することもできます。
Apache Bench でベンチマークを行っている間に、クライアント・リクエストを後で分析するためにログに記録することも可能です。それには mod_log_config.c に配置された Apache Module である mod_log_config を使用します。
ログに書き込む際のフォーマットはカスタマイズ可能で、ログをファイルや外部プログラムに直接書き込むこともできます。またリクエストの特性に応じて個々のリクエストをログに含めるか、除外するかを決定する条件付きロギングも用意されています。
このモジュールでは以下のディレクティブが用意されています。
| ディレクティブ | 説明 |
|---|---|
| TransferLog | ログ・ファイルを作成します。 |
| LogFormat | カスタム・フォーマットを設定します。 |
| CustomLog | ログ・ファイルを定義します。 |
TransferLog および CustomLog ディレクティブを各サーバーで複数回使用すると、各リクエストを複数のログ・ファイルに記録することができます。
Tsung はオープンソースのマルチプロトコル分散負荷テスト・ツールです。このツールが目的とするのは、開発者が IP ベースのクライアント/サーバー・アプリケーションのスケーラビリティーとパフォーマンスをテストできるように、ユーザーをシミュレートすることです。Tsung は、Ajax アプリケーションを実行する HTTP サーバーのロード・テストおよびストレス・テストに使用することができます。また、複数のクライアント・マシンに分散させて、さまざまなシナリオで数千の仮想ユーザーを同時にシミュレートすることもできます。
Bonnie++ では、ディスクの入出力問題を追跡することができます。ディスクの入出力問題は、例えば Ajax アプリケーションでの SQL クエリーの実行速度を遅くし、データベースのパフォーマンスにも影響を与えることがあります。その一例として、クエリーに含まれる単純な EXPLAIN 文と大量のクエリー・ログの分析によってクエリーの実行にかかる時間は長くなります。
C++ で作成された Bonnie++ は、さまざまな UNIX フレーバーでコンパイルして Windows® ベースのマシンで実行することができます。以下のリストに示すのは、UNIX® マシンで使用できる Bonnie++ コマンドの例です。
リスト 1. Bonnie++ コマンド
-u root \
-d /mnt/vol-001/test-vol001/testfiles \
-s 2016M \
-n 10:102400:1024:1024 \
-m bonnie \
-q > /var/tmp/bonnie_test.csv 2> /var/tmp/bonnie_test.out
|
各コマンドの実行内容を以下の表で説明します。
| コマンド | 説明 |
|---|---|
| -u root | ルートとして実行します。 |
| -d /mnt/vol-001/test-vol001/testfiles | テスト・ファイルを作成する場所を指定します。 |
| -s 2016M | 順次テストで作成するファイルのサイズを指定します。このオプションでは、キャッシュのテストになるのを避けるためにシステム・メモリー (1GB) の 2 倍のサイズを指定しています。 |
| -n 10:102400:1024:1024 | ファイルのサイズ、ファイルの最大数、ファイルの最小数、そして作成するディレクトリーの数を指定します。このオプションでは、ファイル・サイズを 10MB、最大ファイル数を 102400、最小ファイル数を 1024、ディレクトリー数を 1024 に指定しています。 |
| -m bonnie | 出力対象のマシン名を指定します。 |
| -q | 出力をファイルにリダイレクトするための表示抑止モードです。stdout は csv フォーマットの出力、stderr は人間が読めるフォーマットでの出力となります。 |
上記の指定内容は変更可能です。Bonnie++ テストは必要な回数、実行できますが (5 回または 10 回)、実行の合間には必ず 60 秒のスリープを設けてください。このスリープ時間ですべてが安定するため、平均的な結果が得られるようになります。
以前は Ethereal と呼ばれていた Wireshark は、マルチプラットフォーム・ネットワーク・プロトコル・アナライザーです。このツールは Ethernet、Token-Ring、FDDI、シリアル (PPP と SLIP)、802.11 ワイヤレス LAN、ATM 接続、および Linux® でサポートされるあらゆるデバイスからのライブ・データを libpcap インターフェースを使って読み取ることができます。
このツールでは、数百のプロトコルの検査、ライブおよびオフラインでのキャプチャー結果の分析、そして 3 ペインのパケット・ブラウザーによる操作が可能です。選択肢には、ネットワーク・トラフィックのダンプ、トラフィックのダンプと分析、あるいはネットワーク・トラフィックのインタラクティブなダンプと分析があります。パケットの ASCII と 16 進ダンプからキャプチャー・ファイルを生成し、そのファイルを編集してマージすることができます。
Wireshark ディストリビューションには以下の man ページが含まれています。それぞれのページの実行内容を調べるには、UNIX / POSIX ではプロンプトで man コマンドを実行し、Windows システムではスタート・メニューから該当する HTML ファイルを表示してください。
| コマンド | 説明 |
|---|---|
| capinfos | キャプチャー・ファイルに関する情報を出力します。 |
| dumpcap | ネットワーク・トラフィックをダンプします。 |
| editcap | キャプチャー・ファイルのフォーマットの編集または変換、あるいはその両方を行います。 |
| mergecap | 2 つ以上のキャプチャー・ファイルを 1 つにマージします。 |
| text2pcap | パケットの ASCII と 16 進ダンプからキャプチャー・ファイルを生成します。 |
| tshark | ネットワーク・トラフィックをダンプして分析します。 |
| wireshark-filter | Wireshark のフィルター構文および参照 |
| wireshark | インタラクティブにネットワーク・トラフィックをダンプして分析します。 |
リアルタイム・アプリケーションや非常に連携性の高いアプリケーションが機能するには、かなりの量の Ajax ポーリングが必要です。ブラウザーは現行ページを更新するためのデータ・チャンクを明示的に要求し、定期的にサーバーをポーリングして新しいイベントが発生しているかどうかを問い合わせます (例えば、5 秒ごとにサーバーに「新規イベントは?」と問い合わせるなど)。
ここで問題となるのは、新規イベントのためにポーリングが繰り返され、それに対するサーバーからのレスポンスがない (例えば、「新規イベントはないため、後で再試行するように」) という状況では、ポーリングの頻度が高いと、新規イベントはないというレスポンスを処理することによって、サーバーのリソースと帯域幅を無駄に使い過ぎるという点です。情報の更新が予測可能なアプリケーション、あるいは更新頻度が比較的低くても問題にならないアプリケーションであれば、ポーリングを使用しても過度の無駄になることはありません。
そこで検討できるのが、Cometd、Lightstreamer、KnowNow、または lighttpd などの Comet サーバー実装への切り替えです。Comet アプリケーションはクライアントとサーバーとの間で長期間有効な HTTP 接続を使用するため、サーバーには遅延応答が可能になり、新しいデータが利用可能になったときにクライアントにプッシュすることができます。これらのアプリケーションは、ストリーミング、または長期ポーリングのいずれかのストラテジーを使用します。
ストリーミング Comet を使用するアプリケーションでは、ブラウザーはサーバーに対して単一のコネクションを開いたら、すべての Comet イベントのためにそのコネクションを張ったままにしておきます。サーバーが新しいイベントを送信すると、そのたびにブラウザーはそのイベントを解釈します。ブラウザー側もサーバー側もコネクションをクローズすることはありません。一方の長期ポーリングでは、ブラウザーがサーバーに対して Ajax スタイルのリクエストを行います。サーバーは、ブラウザーに送信する新規データを入手するまでコネクションをオープンした状態のままにします。イベントを送信した後にサーバーがコネクションをクローズすると、ブラウザーは直ちに新しいコネクションをオープンします。
長期間有効な接続を使用するのに加え、Comet サーバーは通常の Web サーバーよりも並行処理の量を多くし、遅延を短縮し、そしてサーバー負荷を減らすように最適化されます。
Ajax アプリケーションで重い負荷、過剰なポーリング、ネットワーク・トラフィックのボトルネックをテストする前に、使用している JavaScript コードの詳細を検討してください。コードのある行を別の場所に移すことによって、パフォーマンスに違いが出てくる可能性があります。Dojo などの Ajax ツールキットを使用している場合には、JavaScript ファイルを積極的にキャッシュに入れてステータス情報を素早く送信するように Web サーバーを構成することも可能です。また、CSS を利用してページのタグ数を減らすという手段もあります。例えば、以下の 4 行のタグがあるとします (リスト 2 を参照)。
リスト 2. 4 行のタグ
<table><tr>
<td>Hello Dojo</td>
</tr>
</table>
|
この場合、上記の代わりに以下のようにします。
<div class="script2">Hello Dojo</div>
注意する点として、CSS スクリプトが重複しないようにしてください。
アプリケーション内で他にもいくつかの作業を済ませた後、コードのプロファイリングを行って Firebug (Firefox 拡張機能) を補完するのも一考です。コードがループ内にあったため、コンポーネントに対して過剰な呼び出しを行っていたことがわかる場合があります。その場合にはコードをループの外側に移せば、問題は解決するはずです。
2 つの便利な Firefox のアドオンとしては、LiveHTTPHeaders (通常の HTTP トラフィックを表示) と Firebug (リソースのロード時間を測定) が挙げられます。その他の興味深い拡張機能には、RAMBack (メモリー解放時に通知を発行)、Load Time Analyzer (Web ページのロード時間を測定)、YSlow (Web ページを分析)、iMacors for Firefox (Web アプリケーションをテスト)、そして ColorBlind Ext (色覚障害者を支援) などもあります。
Web サイトから直接ダウンロードできる LiveHTTPHeaders は例外として、これらのアドオンを取得するには以下の手順に従ってください。
- Firefox を開きます。
- ツールをクリックし、次にアドオンをクリックします。
- ダイアログ・ボックスの右下隅にある、新しい拡張機能を入手をクリックします。
- セキュリティ警告が表示されたら、OK をクリックしてください。暗号化されたページを表示しようとしていることを警告するボックスには、チェック・マークを付けても付けなくても構いません。
- ダウンロードしてインストールする対象のアドオンを選択します。
- インストールをクリックすると、Firefox が閉じます。
- Firefox を再び開きます。
LiveHTTPHeaders では、通常の HTTP トラフィック、XMLHttpRequest、Comet トラフィックのすべてを、Firefox ブラウザーに表示された完全なヘッダーとともに簡単に表示することができます。この表示から、リモート・サイトが Ajax アプリケーションとの通信に使用している Web サーバーの種類、さらにリモート・サイトから送信された cookie までがわかります。Header Monitor および Header Spy は、ステータスバー・パネルに表示するヘッダーを LiveHTTPHeaders から取得する拡張機能です。Header Monitor は Web サーバーから返された最上位レベルの文書の HTTP レスポンス・ヘッダーを表示します。Header Spy では、最大 5 つのステータスバー・パネルでレスポンスとリクエスト両方のヘッダーを確認することができます。
Firebug ではスクリプト・エラーと XMLHttpRequest 情報を表示できるだけでなく、スクリプトや画像ファイルといった各種リソースのロード時間も測定することができます。Google の Load Time Analyzer ツールを使用すれば、Firefox で Web ページのロードにかかった時間を測定し、グラフに表示することができます。また、YSlow は Yahoo のハイパフォーマンス Web サイトのルールを基準に Web ページを分析し、ロードに時間がかかっている理由を通知します。Mozilla Public License の下で使用が許諾される YSlow は、サード・パーティーがその他の条件によって使用を許諾するパーツからなります。
すべての Web アクティビティーを記録して再現する iMacros for Firefox には、さまざまな Ajax 要素のサポートが組み込まれています。このツールは Web アプリケーションの機能テスト、パフォーマンス・テスト、そしてリグレッション・テストに使用することができます。組み込みの STOPWATCH コマンドが、正確な Web ページ応答時間を測定します。
Fasterfox では、同時接続、パイプライン、キャッシュ、DNS キャッシュ、初期描画遅延など、多数のネットワーク設定とレンダリング設定を調整することができます。このツールの独自のプリフェッチ・メカニズムにより、速度を動的に向上させることも可能です。このメカニズムは、ブラウズ中のページ上にあるすべてのリンクを自動的にロードしてキャッシュに入れることによって、使用されていない帯域幅をリサイクルします。
RAMBack は、パフォーマンス用に確保されたメモリーを解放するよう Firefox に内部通知を発行させます。このツールを使えば、Firefox の内部キャッシュをクリアすることができます。バージョン 2.0.11 までの Firefox で動作する他の拡張機能とは異なり、この拡張機能には Firefox 3.0a8pre-3.0b2 が必要です。
ColorBlindExt は、ページ上の画像とテキストを色覚異常のタイプに応じて処理することによって、色覚に障害のあるユーザーの Web ブラウジングを支援します。このツールには、色覚異常の状態を認識できるようにするための色覚異常検出テストが組み込まれています。
開発チームは Ajax アプリケーション向けに用意された広範なパフォーマンス強化ツールを利用することができます。サーバーのパフォーマンスや、クライアント・サイドでのタスクのパフォーマンス、そしてネットワークのパフォーマンスを向上させるためには、Ajax パフォーマンス改善プロジェクトの作成、テスト、デプロイメントについて事前に計画しなければなりません。パフォーマンスの問題を発見すると同時に解決することで、Ajax アプリケーションの効率的な開発、そして最終用途に大きな効果を上げることができます。
学ぶために
- Judith M. Myerson の連載記事「エンタープライズ規模の SOA における Web サービスの取り扱い」では、エンタープライズ規模の SOA ではどのように Web サービスを扱うかを説明しています。
- Judith M. Myerson の連載記事「WebサービスのコンテキストにてSLAを使用する」では、サービス・レベル・アグリーメントの詳細を説明しています。
-
Tsung、Bonnie++、Wireshark、および Dojo ToolKit の詳細を学んでください。
- Comet サーバー実装用ツールの Cometd、Lightstreamer、KnowNow、lighttpdについて調べてください。
-
Firefox および LiveHTTPHeaders の詳細情報を入手してください。
- Ajax のツールについて詳しく知りたいという方は、「Ajax のツールと手法の調査」 (Gal Shachor、Yoav Rubin、Shmulik London、Shmuel Kallner 共著、developerWorks、2007年7月) を読んでください。
- Judith M. Myerson の著書『The Complete Book of Middleware』は、システム設計の基本原理と優先順位に焦点を当て、e-commerce と分散統合システムの興隆によって生じた新しい要件について強調しています。
- 『Enterprise Systems Integration, Second Edition』を読んで、システム統合を成功させるためのビジネス的洞察力と技術ノウハウを手に入れてください。
- ビジネス・プロセス、運用と実装の問題、リスク、脆弱性、そしてセキュリティーとプライバシーについて説明している「RFID in the Supply Chain」は、組織の将来に役立つはずです。
-
Domino 管理者向けの IBM® Redbook には、サービス・レベル・アグリーメントを開発するための基本が説明されています。
-
テクノロジー・ブックストアにアクセスして、この記事で紹介した技術やその他の技術に関する本を探してください。
-
Ajax resource center にアクセスしてください。ここには記事、チュートリアル、ディスカッション・フォーラム、ブログ、ウィキ、イベント、そしてニュースなど、Ajax プログラミング・モデルに関する情報が豊富に用意されており、ワンストップ・ショップになっています。新しい情報もここに記載されます。
製品や技術を入手するために
-
IBM製品の試用版のダウンロード: 次期開発プロジェクトの構築に、developerWorks から直接ダウンロードできる IBM の試用版ソフトウェアをご利用ください。
議論するために
-
developerWorks blogs: developerWorks コミュニティーに参加してください。