Ajaxの性能検証における課題（1）

Ajaxの性能検証における課題（1）

Ajaxは、優れた操作性と高いレスポンスによってリッチなユーザー・インタフェースを提供します。この一方で、性能検証の側面からは、以下に示すような課題を抱えています。

1. アーキテクチャの違いによる課題

Ajaxは、従来のWebアプリケーションにはないアーキテクチャを持っています。GoogleやYahoo!のWeb画面を見れば分かるように、ユーザー・レスポンスを向上させるため、画面はしばしば複数のコンポーネントに分割されており、それぞれのコンポーネントがサーバーにリクエストを発行します（図2）。

このため、性能検証時には、ページをコンポーネントにブレーク・ダウンして、各コンポーネントごとにパフォーマンスをテストする必要があります。

また、サーバーへのリクエストは、さまざまなイベントによって発生するため、これらのイベントをトリガーとして認識する必要があります。

さらに、リクエストはクライアント上のAjaxエンジンに送られるため、ユーザー・レスポンスを検証する際には、クライアントの処理時間を含めて測定する必要があります。サーバーでの処理よりもクライアントのキャッシュへのアクセスの方が時間がかかる場合もあります。

Ajaxの性能検証における課題（2）

2. 脆弱（ぜいじゃく）な標準、スキル

Ajaxには、多くのフレームワークやツール・キットがあり、詳細に定義された標準がありません。このため、負荷テスト・ツールによる負荷テストの要件として、あるツール・キットはサポートするけれど別のツール・キットはサポートしない、といった限界が生じます。

また、Ajaxは短い期間に急速に発達したため、企業レベルで開発・配備・テストを行うためのスキルが十分に整っていません。アプリケーションにAjaxを取り入れている企業でも、多くは性能テストに関して従来のWebアプリケーションと同じように、ネットワークとサーバーのレスポンスのみをモニターしているのが実情です。

3. リッチなユーザー・インターフェースがもたらす課題

送信ボタンをクリックしないとリクエストがサーバーに送られない従来のWebアプリケーションと異なり、Ajaxアプリケーションではイベントごとにリクエストが発生します。このため、ユーザーがどのような操作を行ったかがレスポンスに影響を与えます。

例えば、Webメールの画面上で、メールを削除したりドラッグ＆ドロップしたりした場合に、サーバーとのやりとりが必要になります。このような操作を1人が行ったときのユーザー体感や、1000人が同時に行った時のユーザー体感を検証する必要があります。

Ajaxでは、サーバー・リクエストの数が従来のWebアプリケーションよりも格段に増加するため、ユーザー数がエンドユーザー体感に大きな影響を与えます。このことは、企業の基幹システムのように、アクセスが一定時期や一定時間帯に集中する傾向のあるアプリケーションでは重大な問題です。

さらに、Ajaxテクノロジをどの程度サポートしているかは、使用するWebブラウザのバージョンやクライアントのOSによって異なるという問題もあります。エンドユーザーがどのWebブラウザやOSを使っているのかも重要な要素になります。

Ajaxには、上記のような課題があります。しかし、既存の負荷テスト・ソリューションでは、これらの課題を解決するのは困難です。

例えば、現在利用されている負荷テスト・ソリューションの多くは、ページごとに複数のHTTPコールを記録・再生することができません。

また、クライアント・プログラムによる処理時間をブレーク・ダウンしてモニターすることができないので、ユーザー体感に影響を与える遅いコールと、それよりもさらに遅いキャッシュ・コールとを見分けることができません。

さらに、特定のフレームワークをサポートしていないため、フレームワークによっては、極めて高レベルの抽象化されたレポートしか提示できません。

AjaxもWebアプリケーションの1つですから、既存のソリューションを使えばネットワークとサーバー間のトラフィックや負荷を測定することはできます。ところが、開発ツールの多くがAjaxを最大限に活用できるようになっている一方で、負荷テスト・ソリューションの多くはAjax環境下でユーザー体感を検証することはできません。