| エンタープライズ：特集 | 2003/10/10 18:00:00 更新 |
特集：第1回 Webアプリケーション開発における諸問題とその解決策 (2/3)
テスト工程におけるパフォーマンスチューニング−Optimizeit Suite
サーブレットをはじめとするJavaによるWebアプリケーション構築のための技術は、パフォーマンス的にも優れている。JVMの問題でなかなかパフォーマンスが出ないという状況は大幅に改善され、JavaでハイパフォーマンスWebアプリケーションを開発する環境は揃ったといってもいいくらいだ。
しかし、現実にはパフォーマンスに関する問題で技術者は眠れない夜をすごしている。ベンダーの宣伝や実証実験、輝かしい成功事例があるにもかかわらずだ。理想と現実のギャップはどこにあるのだろうか。はたして、本当にJavaでパフォーマンスが出るのか。
ひとつ注意しなければならないのは、適切な方法を用いれば極めて効果的にJavaを活用し、十分な成果をあげているという事実があることだ。「うまくいかないのは、Javaのせいだ」というセリフは、「Java」を別の技術にあてはめても同じだ。重要なのは、その技術とどのように付き合うかだ。Javaがひとつやっかいなのは（これは.NETでも同じだが）、抽象的なレイヤーが存在することだ。JVM存在し、J2EEではアプリケーションサーバが存在する。これらのレイヤーが開発者をアプリケーションレベルに集中することを助けているが、一方でメモリ管理やオブジェクトのライフサイクル管理、低レベルでの通信などを隠蔽するため、まったくこれらに気を使わない開発者にとっては、性能を劣化させるブラックボックスとして振舞っているように見えることもあるのだ。
Javaのパフォーマンス問題を解決する重要なポイントはここだ。ブラックボックス化しているJVMやアプリケーションサーバーレベルでの挙動を、アプリケーションレベルから掘り下げて見ることができれば、パフォーマンス劣化の原因となるやっかいなメモリ管理上の問題も発見できるのだ。
テスト工程における「Optimizeit Suite」は、こうした問題に対処するツールだ。JBuilderに完全に統合して使用できる（実際、JBuilder 9 Enterpriseには、Optimize Suite 5.5が標準でバンドルされている）。また、Optimizeit Suiteは、「Profiler」、「Thread Debugger」、「Code Coverage」、「Progress Tracker」の4つのツールによって構成されている。製品は、単体でもJBuilderに統合して使用することもできるが、JBuilderと統合したほうが、開発中にパフォーマンス問題をチェックし、問題箇所を直ちに修正できるから便利だ。
Optimizeitを使用すると、例えば、ガベージコレクションの実行を制御して、メモリの開放状況を監視することができる（画像2）。これにより、オブジェクトへの参照をうっかり残しておいたために、メモリリークが発生するという問題を発見、解決できる。実際、連続的に稼動するWebアプリケーションでは、こうしたケアレスミスが命取りになる。1Kバイトのオブジェクトの参照を残しておいて連続稼動し、1000人のクライアントがこの問題コードを通れば、JVMのヒープを1Mバイト圧迫するのだ。
Thread DebuggerもWebアプリケーション開発では重宝する。基本的にJavaアプリケーションは、マルチスレッドで動作する。サーブレットやJSPの動作では、特にこのことを意識しなければならないが、非同期に並行実行される複数のアプリケーションコードの関連性を把握するのは難しい。Thread Debuggerは、これを視覚的に表示してくれるのだ（図3）。マルチスレッドバグで最も被害甚大なのが、デッドロックだ。同時に実行される別スレッドを意識しなかったために、システム全体が固まってしまうという大惨事も起こり得る。Thread Debuggerは、デッドロックの検出機能も備えており、こうした問題に対処できる。
J2EEアプリケーションのパフォーマンス実現−Optimizeit ServerTrace
J2EE（対応）アプリケーションサーバを用いて、大規模なWebアプリケーションを構築した場合に問題となるのは、「統合」後のパフォーマンス実現問題だ。アプリケーションサーバはさまざまなサービスの集合体であり、互いに連携しあってシステム稼動する。そのため、どこかに性能限界を超える負荷が掛かったり、極端に特定機能に依存するような不適切なコーディングがあってはならない。いくらシステム全体としては余裕があっても十分な性能が発揮できないことになってしまうためだ。多くの場合は、負荷テストツールを使用して状況を把握し、アプリケーションサーバのチューニングなどを施すことで対処する。しかし、問題がアプリケーションコードに起因しているとなると、お手上げだ。
開発ツールは統合前のコードをチェックする。統合後は、アプリケーションサーバーがコードをブラックボックス化する。統合後に、コードレベルまで掘り下げられるツールがあれば、この溝を埋められる。「Optimizeit ServerTrace」はそのような製品なのだ。
「Optimizeit ServerTrace」を用いれば、J2EEアプリケーションの各サービス、コンポーネントの詳細をトレースでき、アプリケーションのどこにパフォーマンスネックがあるのかをすばやく発見することができる。しかも、ソースコードレベルで問題個所をポイントできるため、どのアプリケーションコードを改善すればよいのかが理解できるのだ（図3）。
[藤井 等，ITmedia]
