ログの出力レベルの変更

ログの出力レベルの変更

   JBossはログ出力にlog4jを使っています。その設定ファイルは起動の設定が保存されているディレクトリの「conf\log4j.xml」 です。デフォルトでは「コンソール」と「ファイル」に出力することになっており、コンソールは「INFO」レベル、ファイルは「すべて」（閾値無し）と なっています。

   JBossでは実行時にlog4j.xmlファイルの内容を更新することにより、ログに関する動作を切り替えることができますので、普段出力される ログの量は最低限（例えば「ERROR」レベル）にしておき、何かがおかしくなったときにログの出力レベルを高くするということが行えます。そのため、コ ンソールのログ出力などは極力抑えた内容にすることも可能です（サーバがダウンした原因を調査するときなどにログがないとお手上げになってしまいますの で、ファイルへのログ出力は停止しない方が良いでしょう）。

   また、ログ出力のカテゴリーをアプリケーション・コードに限定することによっても、出力するログの量をかなり減らすことができます。可能であるなら （JBossのソースが信頼できると判断するなら？）JBoss本体部分のログ出力を抑えると良いでしょう。具体的な変更例を以下に掲げておきます。

   コンソールへの出力を停止したい場合は、log4j.xmlファイルの以下の部分を修正します。






   上記のコンソール出力部分を次のように削除します。





   出力カテゴリーを制限する場合は、以下のようにアプリケーション部分のカテゴリーを追加定義します。





ステートレス・セッションBeanのプールサイズ

   J2EEの特徴のひとつとして、必要に応じてリソースが自動的に増加（例えばプールサイズが増える）され、負荷が下がればリソースが解放される（プールサイズが減少する）というものがあります。

   しかし、これはサーバにとって良いことはあまりありません。リソースの作成、解放を繰り返すとメモリ上にすき間がたくさんでき（フラグメンテーショ ン）、ガーベッジコレクションが頻発したりヒープメモリをうまく利用できなくなったりします。こういった事態を避けるためには、はじめから必要な数のイン スタンスをプールして、ずっとその数を維持すれば良いことになります。

   ステートレス・セッションBeanの設定を行うのは、起動設定のディレクトリの中の「\conf\standardjboss.xml」（※注2）です。テキストエディタでファイルを開いて編集します。具体的なサイズ数については適宜調整してください。

（省略）

Standard Stateless SessionBean
false
（省略）



100



   上記の青い部分を以下のように変更します。


100
100
100


未使用サービスの削除

   この作業によってパフォーマンスが改善するわけではありませんが、サーバの起動時間が短くなったり、利用するメモリサイズが小さくなったりといった効果が得られます。

   以前の記事で説明したように、JBossはすべてMBeanというコンポーネント単位でサービスが構築されており、これらの追加／削除が設定ファイ ルを変更することで容易に行えます。すべてのサービスの取り除き方について具体的に説明することは分量的に難しいので、以下のWebページなどを参考に削 除を行ってください。

   英語で記述されていますが、ほとんどの項目が削除するファイルが列挙されているだけですので挑戦してみてください。

設計の見直しを含めたチューニング方法

   以下に説明するチューニング方法は効果が大きいと思われますが、既にある程度アプリケーションが完成してしまっている場合には大きな作業負荷（手戻り）がかかってしまいます。

別JVM上で動作するEJBを同一JVMへ移す

   そもそもEJBはローカル、ネットワークのどちらに配置されていても意識することなく「開発が行える」モデルですが、実行時に大きなパフォーマンス上の影響が出てきてしまいます。

   理由は冒頭で述べたとおり、シリアライゼーションが大きな負荷となってしまうからです。あるJVMから別のJVMで動作しているEJBを頻繁に呼び 出すことは、パフォーマンス上の足かせになってしまいます。JBossにバンドルされているTomcatを使わずに別サーバ（JVM）のWebコンテナを 利用してJBoss上のEJBを呼ぶということも、同様な理由から避けましょう。

Call by Valの設定を止める

   WARやEARのパッケージングの都合上、パッケージ名が同一であるのに実装が異なる（複数バージョンのライブラリが混在しているなど）というようなときに、EJBなどの呼び出しを値渡しで行うことが可能です。

   これは第3回で説明した「ユニファイド・クラスローダ」による副作用が原因です。つまり、同一名で実装の異なるクラスは共存できないためです（もっともこの問題は、事前に注意を払って設計し、適切にパッケージングすれば問題なく回避できます）。

   値渡しでメソッドの呼び出しを行うということは、メソッドを呼び出す度にシリアライゼーションが発生してしまいます。システム規模がある程度以上の 大きさになると無視できないほどのオーバヘッドとなりますので、そういった事態に直面した場合は、WARやEARのパッケージングを見直して、Call by Ref（リファレンス渡しによる呼び出し）へと切り替える必要があります。

   一般的に、Call by ValはCall by Refより10倍ほど遅いといわれています。