WLM
タイムアウト HTTP 作業および Scalable Messaging Support については、WLM タイマーは設定されず、ConnectionResponseTimeout のみ有効となります (ディスパッチ・ウィンドウ全体で有効)。
|
SMF は WLM キュー・タイムにデータを提供します。 |
作業がサーバントに到達するのにかかる時間は、WLM が開始する
サーバント数、ユーザーが開始させる数、
作業が分散されるサービス・クラス数、
ユーザーが実行する処理量などによって決まります。 |
ConnectionIOTimeOut なし。
|
この振る舞いのモニターは、簡単ではありません。
トレース・ポイントをオンにすると、
この入力タイムアウト設定が原因でクライアントが失敗したかどうかが示されますが、
トレースを行うとパフォーマンスに影響します。
|
- メッセージを待ちながら、どれくらい長く制御領域ワーカー・スレッドをブロックするか ?
- 着信 HTTP 要求はどれくらいの大きさであるか ?
これらが大きくなるほど、
ネットワークを介して要求全体を読み込むのにさらに時間がかかる可能性があります。
|
ConnectionResponseTimeout アプリケーション・コンポーネントがトランザクションを開始する場合に、
トランザクション・タイマーが設定されている場合があります。
|
この振る舞いのモニターは簡単ではありませんが、
このタイムアウト条件が発生すると、
コントローラーは、異常終了 EC3 でサーバント (領域) を終了します。 |
- 応答を待ちながら、どれくらい長くクライアントを停止するか ?
- 要求の処理時間が長すぎると判断せずに、
どれくらい長くサーバント (領域) 内のスレッドを応答に関する作業に専念させるか ?
- サーバント (領域) 内に複数のアプリケーション・スレッドがある場合は、
そのうちの 1 つでもタイムアウトになった時点でスレッドはすべて終了されます。
このように作業にロスが生じるので、
こうしたタイムアウトが発生する頻度を少なくした方が良い場合もあります。
|
ConnectionKeepAliveTimeout なし。他のすべてのタイマーが作業の処理に関連するものであるのに対して、
このタイマーは作業が存在しないときに発生する内容に関連しています。
|
なし。 |
要求間の経過時間と、新規セッション確立にかかるコストを比べてください。
新規セッションの始動コストがかからないようにするため、
アイドル・セッションをしばらく維持すべきですが、
リソース使用が積み重なっていくと最終的には問題になるため、
セッションを永続的に維持すべきではありません。
|
要求
タイムアウト (ORB サービス) なし。この変数はクライアント・サイドのタイムアウトで、IIOP のみです。
|
クライアント・サイドで発生するタイムアウトの監視以外はなし。 |
どれくらい長くクライアントを待機させるか ? |
ORB
リスナー・キープアライブ ORB SSL リスナー・キープアライブ なし。これらの変数は、
アイドル期間中のセッション・アクティビティーに関係するもので、IIOP の場合のみ適用されるため、
これらのタイマーと ConnectionKeepAliveTimeout
タイマーに相互作用はありません。
|
SOCK_TCP_KEEPALIVE
値とその結果について詳しくは、TCP/IP APAR PQ18618 をお読みください。 |
アイドル・セッションをタイムアウトにすることが有用か ?
アイドル・セッションは、リソースを消費する可能性があるため、通常は実行しません。
ただし、
タイムアウトの検出に TCP/IP スタック間でネットワーク・トラフィックが必要になります。
他のアイドル・セッションでトラフィックを作成すると、
ネットワークに対して望ましくない影響を与える場合があります。
|
Total
Transaction Lifetime Timeout
この変数は、Maximum Transaction
Timeout
変数によって示される最大値までアプリケーションによってオーバーライドすることができます。
これは、
アプリケーションで設定できるトランザクションの完了時間を制限します。
output タイマーが原因で作業がタイムアウトになる場合もありますが、
トランザクション・タイマーと output タイマーは互いを認識しているわけではありません。
|
コントローラーは、
メッセージ BBOT0003W を発行してタイムアウト条件を示し、
サーバント (領域) を異常終了 EC3、理由コード 04130002 または 04130005 で終了します。 |
- 応答を待ちながら、どれくらい長くクライアントを停止するか ?
- 要求の処理時間が長すぎると判断せずに、
どれくらい長くサーバント (領域) 内のスレッドを応答に関する作業に専念させるか ?
- サーバント (領域) 内に複数のアプリケーション・スレッドがある場合は、
そのうちの 1 つでもタイムアウトになった時点でスレッドはすべて終了されます。
このように作業にロスが生じるので、
こうしたタイムアウトが発生する頻度を少なくした方が良い場合もあります。
|
最大トランザクション・タイムアウト
この変数が設定されている場合、
アプリケーションで設定できるトランザクションの完了時間を制限します。
最大トランザクション・タイムアウト変数が設定されていない場合、アプリケーションのトランザクションは、Total Transaction Lifetime Timeout 変数に設定されている時間制限によって制御されます。
|
なし。 |
考慮事項については、
transaction_ defaultTimeout
と同じ。 |
transaction_
recoveryTimeout なし
|
なし。 |
1 つのコントローラー (領域) が、
未確定のトランザクションを解決するために必要なその他のコントローラーを待っている間はロックされています。
これらのリソースをどれくらい長く保持する余裕があるか ? |