最近、Ajaxの普及により、クライアントからサーバ側にあるコンポーネントを、気軽に呼び出す処理が増えてきています。例えば、HTMLフォームのテキストフィールドに、顧客IDが入力されたら、サーバの顧客コンポーネントを呼び出して、対応する顧客名を取得して表示するといったような処理で使用されます。
こういった単発的かつ単純な処理であれば、多くの場合、それほど気にする必要はないかもしれません。ただし、サーバ側コンポーネントで複雑なビジネスロジックを実行していたり、ある程度まとまった量のデータを取得するような場合は、パフォーマンスの問題に遭遇することがあります。冒頭で述べた通り、どこにでも通用する基準や指標はないですが、どのようなことに気をつければいいかについて、考えてみたいと思います。
不適切な再利用に注意する。
サーバ内部で使用されることを想定したコンポーネントのインタフェースを、そのままクライアントに公開し、「再利用」させてしまう場合には、パフォーマンスの問題が起こりえます。例えば、顧客IDを渡せば、該当する顧客の属性情報(名前、住所、勤務先など。。。)をDBから取得する「顧客情報取得共通処理」と命名されたインタフェースがすでにあるとします。このような類のものは、サーバ側では、多くの箇所で「再利用」され、有用性の高いインタフェースです。 Ajaxクライアント側から見た場合はどうでしょうか？前述のように、単に顧客名を表示する目的であれば、ほとんどが不要なデータである可能性が高いですね。 すでにあるからという理由で無理に「再利用」せず、Ajaxクライアント向けに必要なものだけにしぼった小さいサイズのデータを返すインタフェースを用意しましょう。
呼び出し回数が多くなりすぎないようにする
インタフェースの粒度が小さすぎると、クライアント-サーバ間の通信回数が多くなります。ネットワーク通信には、どうしてもオーバヘッドがあるので、回数多いことがボトルネックの要因になることがあります。解決策は、EJBでよく使われる、「Data Transfer Objectパターン」的に、適切な粒度にまとめることです。 例えば、当たり前のことですが、1つの商品IDに対する商品名取得処理と商品単価取得処理は、1つのインタフェースに統合すべきであることが多いです。複数件のデータ取得を行うことがわかっている場合も、1回の呼び出しで必要な件数のデータが取れるようにしたほうがいいでしょう。
結局のところは、その場の判断で、ちょうどいいところを見つけることが重要です。 もしも、Ajaxに関するパフォーマンスの問題にぶつかった場合、ここで挙げたようなことも、確認してみてください。ソースから発見することはむずかしいかもしれませんが、そのときには、「Webアプリケーションとネットワークのモニタリング」にて紹介した方法で見つけることができます。また、他のメンバーの「パフォーマンスを意識したAjaxのご利用を」にも関連する情報があるので、参考になると思います。