実行スレッドを分離する件について
[前提条件]
[問題点]
[解決案]
■ 構成
■ 分割方法
■ weblogic側設定方法
■ リスクについて
Weblogicの機能で、サーブレット単位で実行キュー(ThreadPoolと認識しております)を分ける事が出来ます。
[問題点]
今回の画面系の機能では、業務上、遅い処理と早い処理があります。
遅い処理例:
・巨大ファイルのアップロード/ダウンロード機能
・数千件データの一括確定処理
現状の設定では遅い処理も早い処理もWeblogic上の同じ実行キューにて処理されてしまう為、遅い処理にて実行スレッドを全て占有されてしまう可能性がございます。
# Thread Poolの占有が問題となっております。
[解決案]
遅い処理用の実効キューと早い処理用の実行キューとに分割する事により、遅い処理によりスレッドを全て占有されてしまっても、早い処理に影響を与えてないようにしてはどうでしょうか。
■ 構成
FLEXを採用し、RemoteObjectを採用している為、以下の2つのパーツに分かれていると認識しております。
# Flashのダウンロードは省きました。
- JSPへとリクエストを発行し、HTMLを取得する。主に画面表示に使用しています。
- flashからRemoteObjectを使用してリクエストを発行する。主にFlash上でのイベント処理に使用しています。
1)に関しての考察
JSP毎にweb.xmlにサーブレットの記述を行えば実行キューの分割が可能です。web.xmlだけの変更で対応可能ですが、本リクエストの処理は非常に軽い為、分割する意味は無いと考えています。
2)に関しての考察
「AMFGatewayServlet」を使用している為、RemoteObject単位での実行キューの分割を行う為にはWebアプリケーション単位での分割(warの分割)が必要と考えています。
■ 分割方法
上記理由より、実行キューの分割をする為にはwar分割するのが良いかと考えます。
# web.xmlだけの変更でどうにかなるのであれば問題ないのですが、何か良い方法をご存知の方がいらっしゃれば、ご連絡下さい。
分割指針としては、機能群単位での分割が良いかと思います。
■ weblogic側設定方法
0. 参考URL
http://jp.bea.com/e-docs/wls/docs70/perform/AppTuning.html
1. 実行キューの作成方法
weblogicの「Administration Console」で新しい実行キューを作成
2. サーブレットおよび JSP の実行キューへの割り当て
初期化パラメータの実行キュー名を識別することにより、コンフィグレーションされた実行キューにサーブレットまたは JSP を割り当てることができます。初期化パラメータは、サーブレットまたは JSP のデプロイメント記述子ファイル web.xml の init-param 要素内で指定されています。実行キューを割り当てるには、次に示すように wl-dispatch-policy パラメータの値としてキュー名を入力します。
例)
<!-- RemoteObject AMF Gateway 1.1 --> <servlet> <servlet-name>AMFGatewayServlet</servlet-name> <display-name>Flash Remoting AMF Servlet</display-name> <description>Servlet-based plugin to Flash Remoting</description> <servlet-class>flashgateway.controller.GatewayServlet</servlet-class> <init-param> <param-name>gateway.configuration.file</param-name> <param-value>/WEB-INF/flex/gateway-config.xml</param-value> </init-param> <init-param> <param-name>whitelist.configuration.file</param-name> <param-value>/WEB-INF/flex/flex-config.xml</param-value> </init-param> <init-param> <param-name>whitelist.parent.node</param-name> <param-value>remote-objects</param-value> </init-param> <init-param> <param-name>wl-dispatch-policy</param-name> <param-value>CriticalAppQueue</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet>
■ リスクについて
本作業を行うに当たり、一番のリスクは、1つのアプリケーションとして動作しているものを複数のアプリケーションに分割する作業である「war分割」かと思います。
# 結合テストあたりからやり直す必要はあるかと思います。
# 分割後の結合テストで問題が発生した場合、どのように対処するかも考えておいたほうが良いかもしれません。
また、複数アプリケーションを1つのServlet上で動作させるには、その分余計なリソース(メモリ等)を消費しますので、その辺りも考慮する必要があるかと思います。
コメント