JBossのチューニング

構築後のチューニングと設計段階のチューニング

   今回はJBossのチューニングに関する話題です。一般的にチューニングを行うのは、パフォーマンステストを行って「実用に耐えない」という判断が下された後に行われる場合が多いと思います。

   そういった、ある程度システムを構築した後に行うパラメータの設定変更やモジュールの入れ替えなどの解説に加えて、設計の段階から考慮するべき事項についても簡単にお話ししようと思います。

パフォーマンスを低下させる原因

   まずはパフォーマンスを悪化させる原因から説明します。パフォーマンスを悪化させる3大悪玉はシリアライゼーション、ディスク・アクセス、ロックだと筆者は考えています。これらはコンピュータ・システムを意図した通りに正しく動作させるための必要不可欠な要素であり、頻繁に実行される処理です。しかしこれらを使いすぎると、パフォーマンスに多大な影響を与えます。

シリアライゼーション

   「シリアライゼーション」（シリアル化）とは、簡単に説明すればコンピュータのメ モリ上にあるオブジェクトをバイト配列に置き換える操作です。実際にシリアライゼーションが発生する場面としては、ネットワークを経由したデータ転送、 データベースやファイルシステムへの書き込みなどがあります。

   また、いったんシリアライズしたものは再び元に戻す必要があります。元に戻すことをデシリアライゼーションといったりしますが、シリアライゼーションとデシリアライゼーションは常に対になって生じます。

   シリアライゼーションに関するネットワーク経由でのデータ転送の例として、RMI（Remote Method Invocation）の場合を考えるとイメージしやすいと思います。RMIはJavaにおける標準のネットワーク経由メソッド呼び出しの手法です。

   ネットワーク上にあるJavaオブジェクトのメソッドを呼び出すときは、通常のローカルにあるJavaメソッドの呼び出しと同様にパラメータを渡す ことができます。パラメータはintなどのプリミティブ型だけでなく、当然通常のJavaオブジェクトを渡すことができます。このときパラメータとして使 われるオブジェクトはSerializableインターフェースを実装していなければなりません（シリアライズして送信するので当然ですね）。

   実際にパラメータのオブジェクトを送信する手順は次のようになります。

1. オブジェクト内のクラス／インスタンス変数（オブジェクトのステート）を「すべて」読み込み、それぞれをバイト配列に変換（シリアライゼーション）する
2. ネットワーク電送路にバイト配列として送信される
3. 受信側でバイト配列を「すべて」読み込み、メモリ上に元のオブジェクトを復元（デシリアライゼーション）する

   こういった処理は非常に単純ですが、すべての情報を走査してその情報をバラし、バ ラされた情報をすべて読み込んで元の状態に戻すという処理は、アルゴリズムなどの工夫によって処理の効率を図ることが難しいのです。そのため、純粋に CPUリソースを消費してしまいます。

   アルゴリズムなどで効率化を図ることが困難である以上、できるだけシリアライゼーション（およびデシリアライゼーション）を回避することがパフォーマンスの向上になります。

ディスク・アクセス

   次に「ディスク・アクセス」です。これはコンピュータ技術者であれば常識となって いる事項だと思いますので簡単な説明にとどめますが、基本はCPUやメモリ上の動作と比較してディスク・アクセスの動作が極端に遅いことが最大の原因で す。極力メモリ上にあるデータだけで処理を完結させることがパフォーマンスの向上に貢献します。

   具体的にはキャッシュの利用を最大化することです。また、ディスク・アクセスが発生するということは、先に述べたシリアライゼーション／デシリアライゼーションがもれなく付いてくるということにも注意してください。

ロック

   悪玉の最後は「ロック」です。ロックは一度にひとつの処理（プロセスやスレッド） しかリソースへアクセスできなくするために使用されます。ひとたびロックが起これば、それが解放されるまでの間は処理が「待たされる」ことになります。ど れだけCPUパワーが余っていても待たされます。

   頻繁なロックの使用が問題になるのは、DBMSやEJBのトランザクションに関連する排他制御やマルチスレッドの排他制御等でしょう。また、永遠にロックが解放されない状態に陥ってしまうデッドロックということも起こりえます。

   ロックを保持する時間を短くする（ロックの粒度を小さくする）ことによりパフォーマンスの向上が期待できますが、あまりに細かくしすぎるとロックの取得／解放の回数が増え、ロックを管理する処理のオーバヘッドが大きくなりすぎて逆効果という場合もあります。