|
|
WebOTX Manual V10.3 (第4版) 目次を表示 |
|
|
|
WebOTX Manual V10.3 (第4版) 目次を表示 |
全エディションにおける Webアプリケーション実行時の Webコンテナのチューニングについて説明します。
Webコンテナには、Webブラウザからのリクエストを処理するプロセッサが存在し、リクエストが来るとスレッドが割り当てられ、プロセッサがリクエスト処理を実行します。
同時に複数のリクエストが来た場合それだけプロセッサを消費しますが、その数を調整することで、同時に処理できるリクエストの数を制限したり、拡大したりすることができます。
同時に処理できるリクエストの数を変更するには、最大プロセッサ数の値を変更します。 この設定はアプリケーションをエージェントプロセスに配備した場合のみ適用されます。
【アプリケーションをエージェントプロセスに配備した場合】
otxadmin を使用して次のコマンドを実行します。
otxadmin> set --user <ユーザ名> --password <パスワード > --host <ホスト名> --port <管理ポート> server.thread-pools.thread-pool.<スレッドプールID>.max-thread-pool-size=<最大数>
get コマンドを利用すれば、現在の値を確認できます。
otxadmin> get server.thread-pools.thread-pool.<スレッドプールID>.*
なお、標準では以下のスレッドプール（スレッドプールID）が定義されています。
外部Webサーバ（リスナID:agent-ajp-listener, tpsystem-ajp-listener）、内蔵Webサーバ（リスナID：http-listener-1, http-listener-2）と連携している場合、共通です。
運用管理コンソール用のリスナ（リスナID:admin-listener）に対する処理スレッドを制御しています。
定義はされていますが、利用しているリスナはありません。
スレッドプールがどのリスナで利用しているかの確認は運用管理コンソールから以下のツリーを選択し、 属性の「スレッドプール」値によって確認することができます。
「アプリケーションサーバ」
「ネットワーク構成」
「ネットワークリスナ構成」
「<リスナ名>」
otxadminコマンドでは以下を実行することで各リスナで利用しているスレッドプールの一覧が表示されます。
otxadmin> get server.network-config.network-listeners.network-listener.*.thread-pool実行例 :
server.network-config.network-listeners.network-listener.admin-listener.thread-pool = admin-thread-pool server.network-config.network-listeners.network-listener.agent-ajp-listener.thread-pool = http-thread-pool server.network-config.network-listeners.network-listener.tpsystem-ajp-listener.thread-pool = http-thread-pool server.network-config.network-listeners.network-listener.http-listener-1.thread-pool = http-thread-pool server.network-config.network-listeners.network-listener.http-listener-2.thread-pool = http-thread-pool
【アプリケーションをプロセスグループに配備した場合】
Webコンテナの最大処理スレッド数を変更するには、運用管理コンソールの以下の設定値を変更します。
[TPシステム] - [アプリケーショングループ] - <アプリケーショングループ名> - [プロセスグループ] -<プロセスグループ名>の順にクリックしていき、 [属性]タブ - [スレッド制御] - [スレッド数]の値を変更します。
Webコンテナのプロセス数を変更するには、運用管理コンソールの以下の設定値を変更します。
[TPシステム] - [アプリケーショングループ] - <アプリケーショングループ名> - [プロセスグループ] -<プロセスグループ名>の順にクリックしていき、 [属性]タブ - [プロセス制御] - [プロセス数]の値を変更します。
これらのパラメータのチューニングの指針については「Webコンテナチューニングの指針」を参照してください。
最大プロセッサ数に応じて最小プロセッサ数の値を変更します。 この設定はアプリケーションをエージェントプロセスに配備した場合のみ適用されます。
otxadmin を使用して次のコマンドを実行します。
otxadmin> set --user <ユーザ名> --password <パスワード > --host <ホスト名> --port <管理ポート> server.thread-pools.thread-pool.<スレッドプールID>.min-thread-pool-size=<最小数>
get コマンドを利用すれば、現在の値を確認できます。
otxadmin> get server.thread-pools.thread-pool.<スレッドプールID>.*
なお、標準では以下のスレッドプール（スレッドプールID）が定義されています。
http-thread-pool
ドメインをWebOTX Webサーバなどの外部のWebサーバと連携した場合、Webサーバとドメインを接続するプラグインモジュールが存在します。
Webサーバやドメインでリクエストを処理するプロセッサ（スレッド）と同様にプラグインで同時にリクエスト処理数を調整することができます。
同時に処理できるリクエストの数を変更するには、connection_pool_size の値を変更します。
connection_pool_size は、ドメインディレクトリの config/WebCont配下の workers.propertiesに定義します。このファイルをエディタで開いて編集してください。
具体的には、次のようになります。"worker.agent-ajp"および"worker.tpsystem-ajp"については通常固定と考えてください（プラグインの負荷分散機能を利用した場合は可変となります）。デフォルト値は 150 です。
値を反映するには Webサーバを再起動する必要があります。
本節では、Webコンテナ上で動作する Webアプリケーションのセッションに関する情報の収集について説明します。
アプリケーションをエージェントプロセスに配備した場合、セッション数を確認するにはアプリケーションの統計情報を採取します。具体的には、統合運用管理ツールや運用管理コンソール、もしくは otxadmin コマンドから Webコンテナのモニタリングレベル "HIGH" にする必要があります。
統合運用管理ツールや 運用管理コンソールからは、「アプリケーションサーバ／モニタリングサービス／モジュールモニタリングレベル」の Webコンテナを "HIGH" にします。otxadmin コマンドからは以下のコマンドを入力してください。
otxadmin> set server.monitoring-service.module-monitoring-levels.web-container=HIGH
上記のコマンドを実行すれば、その時点から、アプリケーション毎のセッション数をそれぞれ次の場所（方法）で確認することができます。
統合運用管理ツール／運用管理コンソール
[統計情報]-[<ドメイン名>]-[アプリケーションサーバ]-[<アプリケーション>]-[<アプリケーション名>]-[session] の順にクリックしていき、「統計値」タブで確認。
otxadmin コマンド
まず、以下のコマンドを実行して配備されたアプリケーションの名一覧を表示させます。
otxadmin> list-components
上記で表示されたリストの中から、希望のアプリケーション名を確認して以下のコマンドを実行します。
otxadmin> get --monitor server.applications.<アプリケーション名>.*.session.*
表示される項目の意味は次の通りです。
|
項目名 |
説明 |
|
activesessionscurrent-Current |
現在アクティブなセッションの数（単位：個） |
|
activatedsessionstotal-Count |
永続化状態からアクティブになったセッションの累計数(単位：個) |
|
expiredsessionstotal-Count |
有効期限が切れたセッションの累計数（単位：個） |
アプリケーションをプロセスグループに配備した場合にセッション数を確認するにはアプリケーションの統計情報を採取します。具体的には、統合運用管理ツールや運用管理コンソール、もしくは otxadmin コマンドから Webコンテナのモニタリングレベル "HIGH" にする必要があります。
統合運用管理ツールや運用管理コンソールからは、「アプリケーションサーバ／モニタリングサービス／モジュールモニタリングレベル」の Webコンテナを "HIGH" にします。otxadmin コマンドからは以下のコマンドを入力してください。
otxadmin> set server.monitoring-service.module-monitoring-levels.web-container=HIGH
上記のコマンドを実行すれば、その時点から、アプリケーション毎のセッション数をそれぞれ次の場所（方法）で確認することができます。
統合運用管理ツール／運用管理コンソール
[統計情報]-[<ドメイン名>]-[TPシステム]-[アプリケーショングループ]-[<アプリケーショングループ名>]-[プロセスグループ]-[<プロセスグループ名>]-[processes]-[<プロセスID>]-[applications]-[<アプリケーション名>]-[<仮想サーバ名>]-[session] の順にクリックしていき、「統計値」タブで確認。
otxadmin コマンド
まず、以下のコマンドを実行して配備されたアプリケーションの名一覧を表示させます。
otxadmin> list-components
上記で表示されたリストの中から、希望のアプリケーション名を確認して以下のコマンドを実行します。
otxadmin> get --monitor tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.processes.<プロセスID>.applications.<アプリケーション名>.*.session.*
表示される項目の意味は次の通りです。
|
項目名 |
説明 |
|
activesessionscurrent-Current |
現在アクティブなセッションの数（単位：個） |
|
activatedsessionstotal-Count |
永続化状態からアクティブになったセッションの累計数(単位：個) |
|
expiredsessionstotal-Count |
有効期限が切れたセッションの累計数（単位：個） |
※ 複数のプロセスを起動している時に該当アプリケーションで合計いくつのセッションが消費されているかを確認するには、全てのプロセスID のセッション数（activesessionscurrent-Current）を見て合計してください。
本節では、Webコンテナのチューニング方法やその指針ついて説明します。
WebOTX Webコンテナでは、利用するエディションによって選択できる動作形態が異なります。Express ではアプリケーションをエージェントプロセスにのみ配備可能で、Standard ではアプリケーションをプロセスグループにも配備可能です。
アプリケーションをエージェントプロセスに配備した場合、Webコンテナは運用管理エージェントのJava VM プロセス(エージェントプロセス)で動作します。これにより、Java EE技術をベースにしたWebベースのシステムを迅速に開発・運用することができます。アプリケーションをプロセスグループに配備した場合、WebコンテナはTPモニタ内の多重化された複数のJava VM プロセスで動作しTPモニタで制御します。このため、高い信頼性が要求される基幹業務システムを構築することができます。また、アプリケーションをプロセスグループに配備した場合、WebOTXシステムを載せたマシンを複数台クラスタ構成で構築したより高信頼・高可用性のある運用をサポートします。それぞれの動作イメージは以下のとおりです。
アプリケーションをエージェントプロセスに配備した場合、内蔵Webサーバを利用した場合の構成例は次のとおりです。
この構成でチューニングするポイントは以下のとおりです。
これらをどのような値にするかは、利用する環境により変化します。(a), (b) については想定される同時アクセス数が、(c),
(d) についてはアプリケーションやその他のライブラリがどれくらいのメモリを必要とするかによって変わってきます。
(a), (b) について、Webコンテナのスレッド数は同時リクエスト数に応じて最小プロセッサ数から最大プロセッサ数に向けて増加していきますが、スレッド数の増加が追いつかない場合、バックログキューにキューイングされます。このバックログキューがあふれるとコネクションが切断されエラーとなります。以下をチューニングの指針としてください。
（最大プロセッサ数 - 最小プロセッサ数）＞ バックログキューの数
このバックログキューは "accept-count" で変更しますので必要に応じて調整してください。
(e)については、クライアント⇔Webコンテナ間のネットワーク速度とWebコンテナが動作しているマシンのCPU性能によって変わってきます。 基本的に、レスポンスデータが少ない場合に圧縮を行うとCPUの無駄使いとなり、圧縮しない場合よりもトランザクション性能が落ちます。ところが、あるサイズ以上のレスポンスデータになると圧縮を行ったほうが行わない場合に比べトランザクション性能が良くなります。この境界点を見極めて、レスポンスを圧縮する最小コンテンツサイズを決定します。
以下に参考データを掲載します。このデータを元にレスポンスを圧縮する最小コンテンツサイズの既定値は 6KB としています。ご利用の環境で想定されるデータを数種類実測し下記と異なる傾向があればこの値を変更してください。なお、この設定は内蔵Webサーバを使用した場合のみ有効です。
またヒープサイズについては、最終的には実際にアプリケーションを配備して動作させ、-verbose:gc オプションを指定してヒープの状況を確認しながらチューニングを行うことになります。
それぞれのパラメータの設定方法については、 [ コンフィグレーション(設定一覧) > Webコンテナ ] を参照してください。
アプリケーションをエージェントプロセスに配備し外部Webサーバを利用した場合、外部Webサーバにプラグイン（mod_jkプラグイン）が配置されます。Webサーバが受け取ったリクエストはプラグインを経由して Webコンテナに送られます。
アプリケーションをエージェントプロセスに配備した場合の外部Webサーバを利用した場合の構成例は次のとおりです。
この構成でチューニングするポイントは以下のとおりです。
これらをどのような値にするかは、利用する環境により変化します。(a), (b), (c), (d) については想定される同時アクセス数が、(e), (f) についてはアプリケーションやその他のライブラリがどれくらいのメモリを必要とするかによって変わってきます。
このうち (a), (b) はお互いの設定値の大小関係により動作が変わってきます。WebOTX Webサーバには同時リクエスト処理数を扱うパラメータとして "ThreadsPerChild" があります。プラグインの "connection_pool_size" はこの "ThreadsPerChild" と一緒に考えます。
WebOTX Webサーバには接続されますが、プラグインの処理数が少ないため 500エラーが多く発生するようになります。しかし、WebOTX Webサーバのバックログキューには溜まらないためレスポンスはある程度確保できます。
ThreadsPerChild と connection_pool_size が同じであるため 500エラーは発生しにくいですが、ThreadsPerChild を超えてきたリクエストは WebOTX Webサーバのバックログキューに溜まります。その結果レスポンスタイムが悪化します。
プラグインでは来たリクエストを確実にさばき、WebOTX Webサーバやプラグインよりも後段で流量の制御を行う場合に設定します。 ThreadsPerChild を超えてきたリクエストは WebOTX Webサーバのバックログキューに溜まります。
(d) については「WebOTX Webサーバの最大同時リクエスト処理数（ThreadsPerChild x Webサーバのプロセス数）＋ 5」としておくことをお勧めます。また、Webコンテナの最大プロセッサ数を超えて受け付けられなかったリクエストは Webコンテナのバックログキューに溜まります。
また、特にヒープサイズについては、最終的には実際にアプリケーションを配備して動作させ、-verbose:gcオプションを指定してヒープの状況を確認しながらチューニングを行うことになります。
それぞれのパラメータの設定方法については、 [ コンフィグレーション(設定一覧) > Webコンテナ ] を参照してください。
アプリケーションをプロセスグループに配備した場合、アプリケーションをエージェントプロセスに配備した場合(外部Webサーバ)と同様に、外部Webサーバにプラグイン（mod_jkプラグイン）が配置されます。
アプリケーションをプロセスグループに配備した場合の構成例は次のとおりです。
上記構成でチューニングするポイントは以下のとおりです。
【AJPリスナ利用時】これらをどのような値にするかは、利用する環境により変化します。(a), (b), (c), (d), (e), (g), (h) については想定される同時アクセス数が、(e), (h), (i) についてはアプリケーションやその他のライブラリがどれくらいのメモリを必要とするかによって変わってきます。
(a), (b) については [アプリケーションをエージェントプロセスに配備した場合（外部Webサーバ）] と同様です。
(c) は接続してくるクライアント数以上の値を設定します。WebOTX Webサーバと連携している場合は Webサーバの httpdプロセス数がクライアント数となります。
(d) は接続してくるクライアント１つあたりの多重度となりますので、WebOTX Webサーバの同時クリエスと処理数（ThreadsPerChild）と同じ数になるように設定します。
(f) はリクエストを処理する時に使用するバッファ領域の個数です。Webコンテナに来たリクエストはこのバッファ領域を利用して処理されます。既定値は5で高負荷時には必要に応じて自動的に追加作成しますが、利用し終わったら破棄し初期値まで戻ります。常に多数のリクエストが同時に来ることが想定される場合はこの値を調整します。次のシステムプロパティで指定します。
-Dcom.nec.webotx.enterprise.web.connector.poolBufferSize=<バッファの個数>
(g) はプロセスグループに来るリクエストがキューイングされるキューです。全てのスレッドはこのキューへの到着を待ち合わせます。このキューを制限することによりオーバしたリクエストを即座にエラーとし、高負荷時でもリクエストのクライアントへのレスポンス時間を保証することが可能です。
(h) は作成するプロセスグループの数、一つのプロセスグループ内で動作するプロセスの数、そして、リクエスト処理性能により決定します。
例えば、あるプロセスグループに300リクエストが同時に来てリクエスト間隔が0.2(リクエスト/秒) の場合、１秒間のリクエスト処理数は「300(リクエスト) x 0.2(リクエスト/秒) = 60(リクエスト/秒)」となります。そして、１スレッドの処理数を 3リクエスト/秒と仮定した場合、プロセスグループ内で必要なスレッド多重度は「60(リクエスト/秒) / 3(リクエスト/秒) = 20(スレッド)」となります。
プロセス多重度を2に設定した場合の1プロセスあたりに必要なスレッド数は、半分の 10 になります。
また、特にヒープサイズについては、最終的には実際にアプリケーションを配備して動作させ、-verbose:gc オプションを指定してヒープの状況を確認しながらチューニングを行うことになります。
それぞれのパラメータの設定方法については、 [ コンフィグレーション(設定一覧) > Webコンテナ ] を参照してください。
アプリケーションをプロセスグループに配備した場合に WebOTX システムを複数配置してロードバランサで振り分ける構成例は次のとおりです。
複数のWebサーバにリクエストを振り分けるためのロードバランサが追加になるだけで、設定項目は [アプリケーションをプロセスグループに配備した場合（単一サーバ）] と同様です。
本節では、外部Webサーバと連携している時、Webサーバプラグインからドメインへのコネクションの接続数の確認方法について説明します。
Webサーバプラグインからドメインへのコネクションの接続数を確認するには、Webサーバプラグインの「Jk Status Manager」を利用します。次の手順で「Jk Status Manager」を有効にします。
${INSTANCE_ROOT}/config/WebServer/httpd.conf を開いてTM_WS_PLUGIN-start 〜 TM_WS_PLUGIN-end で囲まれた部分を編集し、任意のファイル名に変更します。以下では例として".conf" を".conf-status"に変更しています(これ以降の記載でも同様に"-status"を付加したファイル名に変更しています)。
変更前：
# TM_WS_PLUGIN-start
include "${INSTANCE_ROOT}/config/WebCont/mod_jk-24.conf"
# TM_WS_PLUGIN-end
変更後：
# TM_WS_PLUGIN-start
include "${INSTANCE_ROOT}/config/WebCont/mod_jk-24.conf-status"
# TM_WS_PLUGIN-end
${INSTANCE_ROOT}/config/WebCont/mod_jk-24.conf を ${INSTANCE_ROOT}/config/WebCont/mod_jk-24.conf-status にコピーします。
${INSTANCE_ROOT}/config/WebCont/mod_jk-24.conf-status を開いてJkMountFile のファイル名拡張子 ".properties"を ".properties-status"に変更します。
変更前：JkMountFile "${INSTANCE_ROOT}/config/WebCont/uriworkermap.properties"
変更後：JkMountFile "${INSTANCE_ROOT}/config/WebCont/uriworkermap.properties-status"
${INSTANCE_ROOT}\config\WebCont\isapi_redirect.properties を開いてworker_mount_file のファイル名拡張子 ".properties"を ".properties-status"に変更します。
変更前：worker_mount_file=${INSTANCE_ROOT}\config\WebCont\uriworkermap.properties
変更後：worker_mount_file=${INSTANCE_ROOT}\config\WebCont\uriworkermap.properties-status
${INSTANCE_ROOT}/config/WebCont/uriworkermap.properties を${INSTANCE_ROOT}/config/WebCont/uriworkermap.properties-status にコピーします。
${INSTANCE_ROOT}/config/WebCont/uriworkermap.properties-status を開いてstatusワーカにアクセスするためのコンテキストの定義を追記します。この時のコンテキスト名は任意ですが、配備済みのコンテキストと重複しないようにしてください。
/<コンテキスト名>=mystatus
/<コンテキスト名>/*=mystatus
WebOTX Webサーバ(Apache)/IISを再起動します。
「http://[host]:[port]/<コンテキスト名>」にアクセスすると次のような「Jk Status Manager」の画面が表示されます。
この中で「Listing AJP Worker」の下に定義済みのワーカが表示されます。例では「Worker Status for agent-ajp」というワーカが定義されているのが分かります。そして、その下の「State」と記載されている行がそのワーカのコネクション情報が表示されている領域です。
Stateに表示されている項目のうち、コネクションに関する項目とその意味は次の通りです。
なお、「Worker Status for agent-ajp」の左側の「R」をクリックする事でワーカのStatusをリセットする事ができます。