パフォーマンスチューニングの定石を知る：J2EEパフォーマンスチューニング（2）（2/2 ページ）

[清水徳雄，BEA]

（2）チューニングのオーバービュー

　チューニング作業の実際は、アプリケーションとサーバ設定に大別できます。

アプリケーションのチューニング

　アプリケーションのチューニングは、ロジック（Java コード）のチューニングと、(データベース・アプリケーションであれば）データベース・アクセスのチューニングに分けて考えるとよいでしょう。

■アプリケーション・ロジックのチューニング

　ロジックのチューニングとは、詰まるところ問題となるコーディングをほかの方法に書き換えることにほかなりません。Javaプログラミングにおいて性能向上のための定石（あるいはイディオム）がいくつかありますので、アンチパターンに該当する場合は定石に従って書き換えます。書き換えが1つのメソッド／クラスに収まらず、複数のクラスに及ぶ場合もあります。Javaプログラムのパフォーマンス・チューニング一般に関しては、この連載の後半の回で紹介します。

　性能上問題が発生しそうな個所は、あらかじめFactory MethodとStrategyパターンを使用して差し替え可能な実装にしておくと、後のチューニング作業が楽になります（得てして「このような手当てを怠った個所に限って問題が発生するものである」、あるいは、「このような抽象化自体が積もり積もって性能低下をもたらす」という議論はありますが……)。

■データベース・アクセスのチューニング

　データベース・アクセスに予想以上の時間がかかっている場合に行います。J2EEアプリケーションといえども、データベースに関するチューニング手法はほかの形態のデータベース・アプリケーションと変わりありません。データベース・アクセスのチューニングは、場合によっては2けたを超える性能の向上をもたらす場合があります。

●SQLのチューニング

●インデクスの調整を含むSQLのチューニング

●テーブルの再設計 (正規化、あるいは非正規化)

●IOブロック・サイズやキャッシュなどデータベースサーバ設定の変更

　上記のような、データベース・チューニング一般に関する解説は、書籍やマニュアル、データベース・ベンダが配布しているドキュメントを参考にしてください。

　JDBCドライバが複数存在する場合（Type2、Type4などの実装形態が異なるものや、異なるベンダーのものがある場合）は、ドライバを差替えてみるのも1つの方法です。

サーバ設定のチューニング

　サーバ設定のチューニングは、アプリケーションの特定の処理というよりはシステム全体の性能向上を目的として行います。一般に、サーバ設定のチューニングはアプリケーションのチューニングほど劇的な性能の向上は期待できません。コンピュータ資源が豊富な環境では、数％?10％程度の向上が限界ではないでしょうか。

　逆に、資源の乏しい環境（例えばJava VMに割り当てられるヒープの大きさが256Mbytesを下回る環境など)であればそれなりの効果（アプリケーションの種類にもよりますが10?30%程度の向上）が期待できますが、むしろ以下に述べるような事項は、高負荷時の安定稼働を目的として前もって行っておくべきものととらえていただいた方がよいでしょう。

■OSの設定

　OSによって設定方法は異なりますが、以下のような種類のコンフィグレーションに注目し、不足しているようであれば設定値を増やします。

●オープン可能なファイル数

●プロセス数／スレッド数

●データセグメントサイズ／スタックサイズ

●TCP/IPの設定パラメータ

■Java VM

　一部を除き、プラットフォームに依存せずに共通のオプションで設定可能です。

●ヒープサイズ

●GC（ガベージコレクション）の設定

　一般に、JDK 1.3の場合は、

$ java ... -XX:NewSize=128m -XX:MaxNewSize=128m 
-XX:SurvivorRatio=8 -Xms512m -Xmx512m ...

　JDK 1.2 の場合は、

$ java ... -Xgenconfig:64m,64m,semispaces:64m,512m,markcompact 
-Xms512m -Xmx512m ...

をスターティング・ポイントとするのがよいといわれています。

■アプリケーションサーバ

　以下は、WebLogic Serverにおいてパフォーマンス上重要な設定項目です。

●実行スレッド数／リーダー・スレッド数

●JDBCコネクション・プールの設定

●ネイティブI/O

　デプロイメント・ディスクリプタを調整することで、アプリケーション・ロジックに影響を及ぼすことなくある程度チューニングを行うことができます（アプリケーション・ロジックでもサーバ設定でもなく、その中間のコンテナ・レベルのチューニングといえます）。

●EJBのejb-jar.xml、weblogic-ejb-jar.xml、weblogic-cmp-rdbms-jar.xml

●Webアプリケーションのweb.xml、weblogic.xml

　オブジェクトやリソースの競合が原因で、実行スレッド数を増やしても、CPUの使用率が100％に達しない場合があります。このような場合は、複数のJava VMを起動してCPU使用率を上げるのも1つの方法です。競合の発生いかんにかかわらず、一般に1つのマシンで4 CPUを超える場合は、複数のJava VMでの運用を考慮すべきです。なお、Java VMを増やした場合は実行スレッド数やJDBCコネクション・プールの設定を再配分する必要があります。

　クラスタ環境では、クラスタ・メンバ間の通信オーバーヘッドにも注意しておく必要があります。WebLogic Server の場合、クラスタ・メンバ間で次のような情報交換が行われます。

• サーバのハートビート
• JNDIのレプリケーション
• HttpSessionのイン・メモリ・レプリケーション
• Stateful Session Beanのイン・メモリ・レプリケーション

　これらのトラフィックを不必要に増加させてしまうと、性能が低下したりサーバが不安定になったりしますので、アーキテクチャ設計の段階から考慮しておく必要があります。

■Webサーバ／Proxy Plug-in

　例えばApacheであれば、大量のアクセスが急激に集中した場合、負荷の立ち上がりを安定稼働させるために次のパラメータを調整します。

• StartServers
• MaxClients
• MaxSpareServers/MinSpareServers

　Apacheに関しては、少し古い記事ですが「アパッチ・ウェブ・サーバのスピードをチューンしよう」（http://www.hotwired.co.jp/webmonkey/98/04/index2.html）などが参考になります。

　WebLogic ServerのProxy Plug-in の場合、クラスタ・メンバがダウンした際にフェールオーバーが行われるまでの時間を以下のパラメータで調整します(http://e-docs.bea.com/wls/docs61/adminguide/plugin_params.html)。

• ConnectTimeoutSecs
• HungServerRecoverSecs
• ConnectRetrySecs

　上記のうち、OS設定（主にSolarisプラットフォームが対象）、Java VM、アプリケーションサーバに関しては、次回以降の連載で解説する予定です。

プロジェクトの姿勢で必要なこと

　サービスイン後にチューニングで苦しむ前に、あらかじめアーキテクチャ設計、アプリケーション設計、実装の各段階でパフォーマンスに関して考慮しておくことは重要です。最後に、プロジェクトとして取り組んでおくべきポイントを紹介します。

●アプリケーションサーバ製品が備える機能（クラスタリングや、リソースのコネクション・プーリング）が性能に与える効果や影響を理解した上で、アーキテクチャ設計に取り込む。

●アーキテクチャ設計の段階で、プロトタイプを作成し性能評価を行う

●フレームワークに、処理時間をロギングする仕組みを組み込んでおく

●プロジェクトメンバーに、性能上問題が発生しそうなポイントについての共通認識を作り上げておく

●プロジェクトメンバーに、性能向上のための定石を周知しておく

●性能上問題が発生しそうなポイントで、処理時間をロギングしておく

　その他、思いついたこと、気になったことは早いうちに手を打っておきましょう。皆さんも、「あのとき対処しておけばよかったのに……」と後悔した経験は一度ならずあるはずです。

「次回」へ

「J2EEパフォーマンスチューニング」バックナンバー

• Webアプリケーションの高速化実験
• APサーバのチューニング項目を知る
• パフォーマンスチューニングの定石を知る
• 「システムが遅い！」その時どう取り組むか