Java Solution 第6回 読者アンケート結果 〜 Javaシステムのボトルネックとパフォーマンス向上策とは？ 〜 小柴豊 アットマーク・アイティ　マーケティングサービス担当 2002/9/27

　Javaによる開発スタイルは、Web3層システム時代の潮流に乗った感がある。しかしインターネット経由で予期せぬ大量トランザクションなどに晒される今日の環境において、そのパフォーマンスに問題はないだろうか？ またエンジニアはそれをどのように克服しているのだろうか？ Java Solutionフォーラムが実施した第6回読者調査から、その現状をレポートしよう。

Javaシステム開発者の8割が、 パフォーマンスに問題意識を持つ

　まず読者がJavaシステムの開発にかかわる際、パフォーマンスがどの程度問題となっているか尋ねた結果が図1だ。「ほかの言語による開発と比べて、問題となることが多い」「他言語に劣るわけではないが、パフォーマンス向上は大きな課題である」を合わせると、全体の約8割がJavaシステムのパフォーマンスについて問題意識を持っていることが分かった。Javaプログラム自体の実行速度は、JIT／HotSpotなどの技術により進化を遂げているが、ネットワークなどさまざまな要因が絡むシステム全体のパフォーマンスについては、まだまだ課題も多いようだ。

図1　Javaシステムのパフォーマンス問題意識（n=388）

最大のボトルネックは、データベース・アクセス

　では上記のようなパフォーマンス問題を考えるうえで、ボトルネックとなりやすいのは、具体的にシステムのどの部分なのだろうか？ 主な要因を3つまで選択してもらったところ、回答者の約半数が「データベース・アクセス」を挙げたほか、「アプリケーション・ロジック（Javaコード）」「CPU／メモリなどのハードウェア資源」「ヒープサイズ／ガベージコレクションなどJVMの設定」がそれに続く結果となった（図2）。データベース・アクセスについては、Javaだけにとどまらず、Webとデータベースを連携するすべてのシステムに共通したパフォーマンス課題といえるだろう。

図2 Javaシステムのボトルネック部分（n=388）

ボトルネック発見のためのプロファイラ利用状況

　図2で2番目にポイントの高かったアプリケーション・ロジックについては、コード内のボトルネックを発見するために、さまざまなプロファイラ／テストツールが提供されている。そこで読者が日ごろ使用しているツールを尋ねた結果、最も使われていたのはJavaコマンドの「-Xrunhprofオプション」だった（図3）。-XrunhprofはJDKに組み込まれているだけに、エンジニアが最も手軽に活用できるツールといえる。市販製品では、まだ大きなシェアを握るツールが見当たらない中、「Optimizeit」「JProbe」の使用率が比較的高い様子だ。

図3 使用しているプロファイラ／テストツール（n=388）

パフォーマンス・チューニングへの興味内容

　ではJavaシステムのパフォーマンス・チューニングについて、読者は現在どのような情報に興味があるのだろうか？ 3つまでの複数回答で尋ねたところ、「パフォーマンス向上のためのコーディングTips」を筆頭に、「Javaコード内のボトルネックを発見するプロファイリング方法」「パフォーマンスを考慮した、設計段階でのパターン／アンチパターン活用」「ユーザー／開発者間の、定量的なパフォーマンス基準設定方法」といった項目が上位に挙げられた（図4）。パターン活用や基準設定などのポイントが高い点には、パフォーマンス問題に上流段階から取り組もうとするエンジニアの姿勢が表れているようだ。

図4　Javaパフォーマンス・チューニングで興味のあること（n=388）

　最後に、読者が日ごろ実践しているJavaパフォーマンス・チューニング方法について、自由回答で寄せられた中から代表的なコメントをいくつか紹介しておこう。また当フォーラム併設のJava Solution会議室（BBS）にも、「データベース・アクセスの方法について」「StringクラスとStringBufferクラスについて」といったスレッドが随時立っているので、下記以外に有効な方法や体験をお持ちの方がいれば、ぜひ積極的な投稿をお願いしたい。

○データベース／データベース・アクセス関連

• データベースのコネクション・プーリングは必須
  
• データソースやホームインターフェイスなど、JNDIルックアップを行って取得したオブジェクトはキャッシュしておく
  
• データベース・アクセスには極力PreparedStatementを使用する
  
• SQL取得結果のキャッシュであるResultsetを保持する部品クラス作成
  
• SQL文の実行計画をexplainして調査することが多い

○そのほか

• Stringの連結は行わず、StringBufferを使用する
  
• オブジェクトの生成頻度（new）に留意して設計する。つまり無駄にインスタンスを生成しないようにする
  
• public static finalで定義するなど、オブジェクトの作成を極力しない
  
• 画面表示の際のHTTPデータ量の制限
  
• GCの発生頻度、タイミングに合わせたヒープ領域内部サイズのチューニング
  
• 設定データ保持系のBeanは、Singletonパターンで実装する
  
• J2EEパターンの適用（ValueObject）

■調査概要

• 調査方法：Java SolutionフォーラムからリンクしたWebアンケート
  
• 調査期間：2002年7月8日〜8月7日
  
• 回答数：440件（うち、Javaシステム開発者388件を集計）
  

　

関連記事

連載 J2EEパフォーマンスチューニング：「システムが遅い！」その時どう取り組むか

連載 J2EEパフォーマンスチューニング：パフォーマンスチューニングの定石を知る

事例に学ぶWebシステム開発のワンポイント：キャッシュが性能劣化をもたらす謎を解く

　

読者調査記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）