ADFアプリのリソースチューニング

ADFアプリのリソースチューニングというと、独自のチューニングポイントとしてアプリケーション・モジュール・プールがありますが、ここでは大抵のJavaEEアプリで問題となるHTTPセッションタイムアウトとデータベース接続プールについて考えます。

HTTPセッションタイムアウト

HTTPセッションタイムアウト時間は、5分程度の短めの時間を設定しておくのがよいようです。

従来の(非AJAXな)JavaEEアプリとして業務アプリなどを作る場合は、30分や60分といった長めの時間を設定することが多かったと思います。このようなアプリケーションでは、画面遷移のタイミングでしかリクエストが発生しないために、入力画面での長考によってタイムアウトが頻発することになるからです。

また、大抵のORMフレームワークでは、HTTPリクエストからレスポンスの間にトランザクションを完結させるように作ってあるので、セッション属性に積むデータ量にさえ気をつければ、HTTPセッション残留によるリソースの専有はそれほど気をつけなくても良かったということもあります。

ADFの場合は事情が変わります。ADFアプリケーションでは、複数のリクエストを跨がってトランザクションが維持されます。これは、内部的には、HTTPセッションとDB接続が、アプリケーションモジュールを介して結び付けられることによって実現されています。このため、セッションの長時間残留はDB接続の枯渇に繋がります。

一方で、ADF Facesの画面は部分書き換えや値検証などのためにリクエストが頻発するため、作業中にセッションタイムアウトに至る確率はかなり抑えられます。また、デフォルトの設定では、2分ほどサーバとの通信がない場合はダイアログが表示され、「OK」をクリックするとサーバ通信を行うので、ここでもタイムアウトの発生を抑止できます。

このような事情から、HTTPセッションタイムアウトは短めに設定するのがよいです。

データベース接続プール

データベース接続プールについては、最大数を多めに設定しましょう。同時利用ユーザが10名程度でも、接続プールの最大値は50以上は確保するべきです。

すでに述べた通り、ADFアプリでは複数リクエストに跨がってDB接続を保持しますので、リクエスト単位で開放される従来型のフレームワークに比べて、同時利用ユーザ数に対するDB接続使用数が格段に増加します。

また、複数のアプリケーションモジュールを構成するアプリケーションの場合、トランザクション分離のために、アプリケーションモジュールごとに個別のDB接続を保持することもあります。つまり、ひとつのセッションで複数の接続を専有することもありえます。

(ちなみに、1回限りのサービス提供のためのアプリケーションモジュールの場合、サービスメソッドの最初でgetDBTransaction、最後でDBTransaction#closeTransactionを呼ぶようにしましょう。DB接続の保持期間をメソッド実行中のみに制限できます)

今時のOracle Databeseであれば、MAX_SESSIONは数百程度に設定しても割と平気なので、ケチケチせずに行きましょう。