Web 層のパフォーマンス
このコンテンツでは、Web 層のパフォーマンスの調整について説明します。
casso127jpjp
このコンテンツでは、Web 層のパフォーマンスの調整について説明します。
2
エージェントが Web サーバまたはアプリケーション サーバに送信されたリクエストをインターセプトする場合、エージェントはポリシー サーバに以下の呼び出しを行います。
- isProtected
- isAuthenticated
- isAuthorized
これらの各呼び出しによって、Web 層のエージェントとアプリケーション層のポリシー サーバの間でトラフィックが生成されます。以下の設定によって、Web 層のパフォーマンスを調整できます。
- ポリシー サーバ リクエストのタイムアウト間隔を変更します。
- エージェントがポリシー サーバ接続に使用できるソケットの数を変更します。
- エージェント キャッシュを使用して、エージェントが ポリシー サーバに対して行う呼び出しの数を減らします。
以下の図でグレー表示された項目には、Web 層のパフォーマンスに影響する設定が含まれます。

サーバのパフォーマンス
エージェントは、サポートされている多くの Web サーバおよびアプリケーション サーバにインストールできます。ホスト サーバのパフォーマンスにより、
Single Sign-On
Web 層のパフォーマンスが決まります。以下のアイテムは、Single Sign-On
での Web サーバのパフォーマンスに影響します。- Web サーバのプロセッサ速度
- Web サーバのメモリ量
エージェントのパフォーマンス
以下の要因がエージェントのパフォーマンスに影響します。
- Web サーバまたはアプリケーション サーバの CPU および使用可能なメモリ。
- ポリシー サーバの遅延(ポリシー サーバがエージェントのリクエストに応答する速さ)。
リクエスト数を処理するために使用できる Web サーバが少なすぎる場合、以下のタイプの問題が発生する場合があります。
- ユーザのログインが遅延する、またはできません。
- 要求したリソースを受け取るユーザ側で遅延が発生します。
- CPU 使用率が最大容量、またはそれに近くなります。
ピーク時に各 Web サーバまたはアプリケーション サーバによってサービスされるリクエスト数を予想することは、環境の Web サーバの理想的な数を判断するのに役立ちます。
以下のいずれかの方法を使用してリクエスト数を概算します。
- 容量計画作業を実行します。
- 環境内の各エージェントのSingle Sign-Onアクティビティ レポートを生成します。
- Web サーバ用にパフォーマンス レポートを生成します。詳細については、Web サーバ ベンダーによって提供されているドキュメントを参照してください。
Web 層ソケットの使用
エージェントの起動時に、ポリシー サーバ上のホスト設定オブジェクト内の MinSocketsPerPort パラメータによって指定された数のソケットが開きます。受信されるリクエストが多い場合、最大ソケット数に達するまで、エージェントは指定された数の新しいソケットを接続プールに追加します。すべてのソケットが使用されると、以下のいずれかのイベントが発生するまで、その他のリクエスト(300 まで)はキューに保持されます。
- ソケット ペアが使用可能になり、リクエストがポリシー サーバに送信される。
- リクエストがタイムアウトになり、ユーザはリソースへのアクセスを再試行する必要があります。
ポリシー サーバ上のホスト設定オブジェクトには、使用されるソケット数を制御するパラメータが含まれます。
高負荷時のリクエストのタイムアウト間隔の増加
ネットワークが以下のいずれかの状況である場合、エージェントからのリクエストがポリシー サーバのキューで保持される期間の延長を検討してください。
- 過剰トラフィック
- 遅い接続
ポリシー サーバ上のホスト設定オブジェクト内の RequestTimeout パラメータは、エージェントがポリシー サーバからの応答を待つ期間を制御します。間隔が短すぎる場合、リクエストはタイムアウトになり、ユーザはエラー メッセージを受信します。
エージェントに対して使用できるソケット量の増加
容量計画の概算によって、エージェントごとのユーザ リクエスト数が一定期間に 60 を超える(20 のリクエストが処理中で 40 がキュー内にある)ことが確認された場合は、
MaxSocketsPerPort
パラメータの値を増やします。管理 UI で MaxSocketsPerPort パラメータの値を増やした後に、ポリシー サーバ管理コンソールの[最大接続数]設定が、環境のすべてのエージェント プロセスに対応するために十分であることを確認します。この設定によって、特定のポリシー サーバに対して使用できる最大接続数が決まります。
注
: マルチプロセス Web サーバ(pre-fork モードの Apache ベース サーバなど)については、このソケット数を 1 に減らすことができます。各プロセスがポリシー サーバと通信するために使用するのは 1 スレッドのみなので、必要なソケットは 1 つのみです。NewSocketStep 設定の増加
エージェントがピーク期間に接続プールからの追加のソケットを必要とする場合、NewSocketStep パラメータによって各回に取得するソケット数が決まります。
NewSocketStep パラメータの値の設定が低すぎる場合、エージェントがソケット接続の作成に余分な時間をとるので、ピーク期間の応答時間に影響します。
遅い応答時間を回避するには、容量計画の概算を使用してエージェントが処理するリクエスト数を判断し、NewSocketStep パラメータの値をそれに応じて増やします。
このパラメータの理想的な数は、Web またはアプリケーション サーバの負荷が増加するときに、リクエスト用のソケット作成にエージェントが時間を使い過ぎることを防ぐために十分な大きさの数です。
環境で最適に動作する設定を見つけるまで、様々な設定での試行をお勧めします。
注
: マルチプロセス Web サーバ(pre-fork モードの Apache ベース サーバなど)については、このソケット数を 1 に減らすことができます。各プロセスがポリシー サーバと通信するために使用するのは 1 スレッドのみなので、必要なソケットは 1 つのみです。ポートあたりの最小ソケット数設定
エージェントの起動時に、ポリシー サーバ上のホスト設定オブジェクト内の MinSocketsPerPort パラメータによって指定された数のソケットが開きます。これらのソケットによりポリシー サーバへの常時接続が維持されます。
ほとんどのタイプの Web およびアプリケーション サーバ(ワーカー モードの Apache ベースのサーバを含む)については、このパラメータをデフォルト設定のままにすることをお勧めします。このパラメータを増やすと、エージェントがリソースに対するリクエストを受信していないときでもソケットを開いたままにすることによって、不必要にソケットを占有します。
注
: マルチプロセス Web サーバ(pre-fork モードの Apache ベース サーバなど)については、このソケット数を 1 に減らすことができます。各プロセスがポリシー サーバと通信するために使用するのは 1 スレッドのみなので、必要なソケットは 1 つのみです。ソケット設定間の関係の例
使用している Web サーバのタイプによって、ポリシー サーバ上のソケット割り当てパラメータ間の関係が決まります。
単一プロセス複数スレッドの Web サーバは複数プロセス単一スレッドの Web サーバとは異なる動作をするので、ポリシー サーバ上のソケットの割り当ては Web サーバの各タイプによって異なります。
このタイプを判断するには、Web サーバのベンダーのドキュメントを参照してください。
以下の図では、単一プロセス、複数スレッドの Web サーバの式について説明します。

以下の図では、複数プロセス、単一スレッドの Web サーバの式について説明します。

以下の図では、複数プロセス、複数スレッドの Web サーバの式について説明します。

ソケット設定を調整するときに、前述のいずれかの式をガイドとして使用します。
エージェントとポリシー サーバ間のトラフィックの低減
エージェントは、エージェントとポリシー サーバ間のトラフィック量を減らすために併用できる複数のキャッシュおよび設定パラメータを使用します。一般的に、これらの設定は、ポリシーおよび URI が通常は静的なままである環境で最も効率的です。
エージェント キャッシュが動作する仕組み
Single Sign-On
エージェントは、ポリシー サーバに接続する前に、以下のキャッシュで情報を検索します。- リソース キャッシュ
- セッション キャッシュ
- 許可キャッシュ
キャッシュからの情報の取得はポリシー サーバへの問い合わせより迅速なので、パフォーマンスが向上します。以下の図では、このプロセスについて説明します。

リソース キャッシュ
各エージェントは、リソース キャッシュを使用して、ポリシー サーバから受信する以下の情報を一時的に格納します。
- リソースが保護されているかどうか
- ポリシーに含まれる任意の追加レスポンス属性
エージェントはポリシー サーバに問い合わせる前に、リソースが保護されているかどうかを決定するためにリソース キャッシュを検索します。リソースがキャッシュに存在する場合、エージェントはポリシー サーバへ IsProtected 呼び出しを行わないので、ポリシー サーバへのトラフィックが軽減されます。
2 つのエージェント設定パラメータがリソース キャッシュに影響します。
Single Sign-On
の展開を計画する際に、以下の点を考慮します。- リソース キャッシュのタイムアウトキャパシティ計画テストの結果に基づいたエージェント リソース キャッシュのタイムアウト間隔をお勧めします。タイムアウト間隔が短すぎると、リソース キャッシュの有効性が制限されます。エージェント設定の ResourceCacheTimeout パラメータの値が、リソース キャッシュのタイムアウト間隔を決定します。
- リソース キャッシュのタイムアウトキャパシティ計画テストの結果に基づいたエージェント リソース キャッシュのタイムアウト間隔をお勧めします。タイムアウト間隔が短すぎると、リソース キャッシュの有効性が制限されます。エージェント設定の ResourceCacheTimeout パラメータの値が、リソース キャッシュのタイムアウト間隔を決定します。
リソース キャッシュおよび URL クエリ文字列
URL クエリ文字列を使用するアプリケーションを保護する場合、クエリ文字列内のデータを無視するように Web エージェントを設定することにより、今までどおりリソース キャッシュを利用できます。クエリ文字列データが無視されると、省略された URL がリソース キャッシュに格納されます。クエリ文字列は、Web エージェント設定で IgnoreQueryData パラメータの値を設定することにより無視されます。
重要:
URL クエリ データに依存するポリシーがある場合は、この設定を有効にしないでください。次の表では、URL 内のクエリ文字列を無視することにより、リソース キャッシュのアイテムを使用するか、または代わりに Web エージェントがポリシー サーバに問い合わせるかを決定する方法を示しています。
クエリ文字列を持つ要求された URL | キャッシュに格納される省略された URL | キャッシュ アイテムの使用 | 問い合わせ先ポリシー サーバ |
/exampleapplication/page1.html?user=firstuser | /exampleapplication/page1.html | いいえ | はい |
/exampleapplication/page1.html?user=seconduser | はい | いいえ | |
/exampleapplication/page2.html?user=seconduser | /exampleapplication/page2.html | いいえ | はい |
セッション キャッシュ(認証)
各エージェントは、セッション キャッシュを使用して、ポリシー サーバがすでに認証したユーザの認証情報を格納します。
エージェントはセッション キャッシュを検索して、ポリシー サーバに認証を問い合わせる前に、ユーザが認証済みであるかどうかを判断します。セッション キャッシュによって、ポリシー サーバへの認証呼び出しの数を減らすことにより、パフォーマンスが向上します。
以下のいずれかのイベントが発生すると、ユーザの認証は終了します。
- ユーザがログアウトします。
- ユーザに関連付けられたセッションが期限切れになります。
- キャッシュ内の項目の経過時間が 60 分を超えます。
認証情報はセッション キャッシュから削除され破棄されます。
許可キャッシュ
各エージェントは、許可キャッシュを使用して、ポリシー サーバがすでに許可したユーザの許可識別を格納します。
エージェントは許可キャッシュを検索して、ポリシー サーバに許可を問い合わせる前に、ユーザが許可済みであるかどうかを判断します。許可キャッシュによって、ポリシー サーバへの許可呼び出しの数を減らすことにより、パフォーマンスが向上します。
以下のいずれかのイベントが発生すると、ユーザの許可は終了します。
- ユーザがログアウトします。
- ユーザに関連付けられたセッションが期限切れになります。
許可識別はキャッシュから削除され破棄されます。
セッション キャッシュおよび許可キャッシュの設定
ポリシー サーバ設定とエージェント設定パラメータの組み合わせによってセッション キャッシュおよび許可キャッシュを制御します。容量計画の結果を参考にして、
Single Sign-On
展開内の以下の設定に最適な値を決定します。- セッション タイムアウト次のようにセッション タイムアウトを設定することをお勧めします。
- 保護されているアプリケーションに最大数のユーザがアクセスしている持続時間に合わせて最大セッション タイムアウトを設定します。
- アイドル セッション タイムアウトを、次のすべての基準を満たす間隔に設定します。
- 作業中にユーザがログアウトしないために十分に長い。
- アプリケーションが使用されていないとき(ユーザがログアウトせずに、コンピュータを離れる場合など)に、ユーザを自動的にログアウトさせるために十分に短い。
- セッション キャッシュのサイズこのキャッシュのサイズは、セッション タイムアウト間隔中の持続期間にリソースへのアクセスが予想されるユーザ数に基づいて決定します。サイズの見積もりには、セッション タイムアウト期間中にログアウトして再びログインするユーザも含めます。サイズの見積もりには、ほとんど要求を行わないと予想されるユーザは含めないでください(こうしたユーザはセッション キャッシュおよび許可キャッシュにわずかの影響しか及ぼさないからです)。MaxSessionCacheSize という名前の Web エージェント設定パラメータは、セッション キャッシュと許可キャッシュの両方のサイズを決定します。
キャッシュおよび匿名ユーザ
Single Sign-On
によって提供される匿名認証方式は、それらが保護するリソースへのアクセスを制御しません
。匿名認証方式は、ネットワーク上の未確認のユーザに対して以下を許可します。- ユーザがサイトに戻る頻度を追跡します。
- 特定のユーザがサイトにアクセスしている間に実行することを追跡します(アクセス中にユーザが表示したページなど)。
- 特定のユーザに対してパーソナライズされたコンテンツを表示します。
ユーザが匿名認証方式によって保護されたリソースをリクエストすると、ポリシー サーバは GUID (グローバル一意識別子)を割り当てて、関連するユーザのブラウザに格納します。
Single Sign-On
は、この GUID を使用してユーザを識別します。匿名認証方式を使用する場合は、以下のアイテムを実装すると、
Single Sign-On
環境のパフォーマンスが向上する可能性があります。- 匿名のリクエストを処理する個別の Web サーバ。
- それぞれの Web サーバ上で Web エージェントを設定し、CacheAnonymous パラメータを設定することによって匿名のリクエストをキャッシュします。
個別の Web サーバおよび Web エージェントを匿名のユーザに対して使用することにより、保護されたリソースに対するリクエストを処理する他の Web サーバ上のキャッシュが頻繁にフラッシュされないようにします。
Web エージェントのパフォーマンスに影響する他のパラメータ
以下のパラメータも Web エージェントのパフォーマンスに影響します。
- PSPollInterval
- IgnoreExt
- IgnoreURL
ポリシー サーバのポーリング間隔パラメータ
エージェントは定期的にポリシー サーバに問い合わせて、更新されたポリシーや暗号化キーを受信します。ポリシー サーバに問い合わせる時間間隔は、PSPollInterval エージェント設定パラメータの変更によって調整できます。
時間間隔を増やすことで、エージェントとポリシー サーバの間の不要なトラフィックを低減できます。環境に以下のいずれかの特徴がある場合は、間隔の増加を検討してください。
- 多数のエージェントがあります。
- ほとんどのポリシーは静的であり、頻繁に変わることはありません。
重要:
PSPollInterval パラメータの値を増やすと、エージェントがポリシー変更を適用するタイミングにも影響が及びます。たとえば、勤務が終了した従業員のアクセスを無効にするため、10:30 にポリシーを変更し、PSPollInterval パラメータの値が 3600 (1 時間の秒数)であるとします。この場合、Web エージェントでは、変更されたポリシーを 11:30 まで適用しません。拡張パラメータの無視
Single Sign-On
で保護するリソースに保護しない
多くのイメージまたはファイルが含まれる場合、特定のファイル拡張子を無視するように Web エージェントを設定することにより、Web エージェントとポリシー サーバの間のトラフィックを低減できます。Web エージェントはポリシー サーバに対して以下の呼び出しを行わ
ない
ため、パフォーマンスが向上します。- IsProtected
- IsAuthenticated
- IsAuthorized
- ログイン
関連付けられたリソースの要求は Web サーバに直接渡され、ユーザはアクセスを付与されます。
最初に保護するリソースを特定すると、Web エージェントに無視させるファイル拡張子があれば、その決定に役立つ場合があります。
無視するすべてのファイル拡張子を Web エージェント設定の IgnoreExt パラメータに追加します。
URL パラメータの無視
特定のサブディレクトリのリソースを非保護のままにする場合、特定の URI (Uniform Resource Identifier)を無視するように Web エージェントを設定できます。
たとえば、各 Web サーバに pictures という名前のサブディレクトリがあり、それらのディレクトリを非保護のままにする場合、Web エージェント設定で IgnoreURL パラメータを設定できます。
Web エージェントはポリシー サーバに対して以下の呼び出しを行わ
ない
ため、パフォーマンスが向上します。- IsProtected
- IsAuthenticated
- IsAuthorized
- ログイン
関連付けられたリソースの要求は Web サーバに直接渡され、ユーザはアクセスを付与されます。
ロード バランシングによるエージェント パフォーマンスの向上
複数のエージェントとポリシー サーバがあるときは、ダイナミック ロード バランシングによって遅延が軽減され、スループットが向上します。これはエージェントがすべてのポリシー サーバ間でリクエストを分散させるためです。ダイナミック ロード バランシングを使用すると、エージェントはポリシー サーバに迅速にアクセスできるようになり、認証および許可の効率が向上します。
Single Sign-On
は、複数のポリシー サーバとの通信でソフトウェア ベースのフェールオーバおよびロード バランシングを提供します。[ホスト設定オブジェクト]の EnableFailover パラメータでは、以下のいずれかの値を使用して、Web エージェント接続の処理方法を決定します。- 値が yes に設定されていると、エージェントは常に、[ホスト設定オブジェクト]でリスト表示された(左から右に)最初のポリシー サーバに接続しようとします。複数のポリシー サーバがある場合、すべてのエージェントは最初のポリシー サーバへの接続を試行します。リスト内の最初のサーバが利用不能でない限り、リスト内の他のサーバはアクセスされません。高ボリューム環境では、この設定はロード バランシングよりも効率が低くなります。これは一部のポリシー サーバで多くの接続を処理する一方で、他のポリシー サーバで少ない接続(存在する場合)が処理されるためです。
- 値が no に設定されていると、ロード バランシングが有効になります。エージェントは、[ホスト設定オブジェクト]にリストされているすべてのポリシー サーバ間で、ラウンド ロビン方法によりそれらのリクエストを負荷分散させます。複数のポリシー サーバを使用するときにスループットが向上するので、この設定をお勧めします。ロード バランシング ポリシー サーバの 1 つが利用不能になると、引き続きフェールオーバが行われます。
また、
Single Sign-On
は、エージェントとポリシー サーバの間の接続の高度なダイナミック ロード バランシングを提供するためにハードウェア ロード バランサの使用をサポートします。仮想 IP アドレスによって複数のポリシー サーバを表示するように設定すると、ハードウェア ロード バランサはその仮想アドレスと関連付けられたすべてのポリシー サーバ間の負荷の分散を処理します。エージェントはフェールオーバまたはロード バランシングを処理する必要がないので、Single Sign-On
ロード バランシングを無効にするために EnableFailover パラメータを yes に設定します。[ホスト設定オブジェクト]内のポリシー サーバのグループを表示する VIP(複数可)のみを設定します。マルチスレッド Web およびアプリケーション サーバの場合の フェールオーバおよびロード バランシング
マルチスレッド Web およびアプリケーション サーバ(Sun Java System、IIS、worker モードの Apache ベース サーバ、または WebSphere Application Server など)上で実行される エージェントは、起動時にポリシー サーバに対して最小数のソケットを開きます。
使用している環境で、ポリシー サーバ間のフェールオーバまたはロードバランシングを設定すると、エージェントは、起動時に最小数のソケットを開きます。負荷分散されたポリシー サーバへの接続は同じ方法で行われますが、それぞれのポリシー サーバに対しより少ないソケットが開かれます。これはそれぞれがリクエストの合計の半分のみを取得するためです。
フェールオーバを設定している場合、エージェントとプライマリポリシー サーバの間に通信エラーが発生すると、フェールオーバ ポリシー サーバへの接続が使用されます。フェールオーバはサーバごとに行われるため、プライマリ ポリシー サーバへの接続とフェールオーバ ポリシー サーバへの接続が同時にアクティブになることがあります。プライマリポリシー サーバが復旧しても、フェールオーバ サーバに対するソケットは開いたままです。新しいソケットはすべて、プライマリ ポリシー サーバに対して開かれます。
マルチプロセス Web およびアプリケーション サーバの場合の フェールオーバおよびロード バランシング
マルチプロセス Web またはアプリケーション サーバ(プリフォーク モードで実行される Apache ベース サーバなど)上で実行されるエージェントは、フェールオーバが行われるかどうかにかかわらず、
すべての
設定済みポリシー サーバに対し同数の接続を開きます。フェールオーバは、それぞれの子から独立して行われます。これは、それぞれの子プロセスにポリシー サーバに対する独自の接続が存在するためです。このため、フェールオーバの実行によって、各ソケットに関する 500 エラーが発生します。プライマリ ポリシー サーバの復旧後に、フェールオーバ サーバに対するソケットは開いたままです。新しいソケットはすべて、プライマリ ポリシー サーバに対して開かれます。
Web サーバ、Web エージェント、および Web サーバ プロセス
各エージェントには、専用の Web サーバ インスタンスが必要です。たとえば、IIS Web サーバはインストールされたコンピュータの単一のインスタンスを使用して動作します。IIS エージェント数は IIS Web サーバ数と同じです。
1 台のコンピュータにつき複数のインスタンスをサポートするその他の Web サーバの場合は、各インスタンスに対して 1 つのエージェントをインストールおよび設定できます。たとえば、1 台のコンピュータで 3 つの個別の Web サーバ インスタンスを実行することができます。各インスタンスには、専用のエージェントがあります。そのため、1 台のコンピュータが 3 つのエージェントを操作します。
Apache Web サーバの場合、以下のマルチ処理モジュール(MRM)が、エージェント プロセスのポリシー サーバへの接続方法に影響します。
- プリフォーク モード追加リクエストを処理する子プロセスを作成します。
- ワーカー モード接続プールから追加のスレッドを取得して、追加のリクエストを処理します。
Apache ベースの Web サーバ ワーカー モードを使用する Web エージェントとポリシー サーバの通信
ワーカー モードの Apache ベース Web サーバは、スレッドを使用してポリシー サーバへの接続を処理します。スレッドは必要に応じて接続プールから取得されて、高負荷時にポリシー サーバへの追加の接続を作成します。
以下の図では、このプロセスについて説明します。

Apache ベースの Web サーバ プリフォーク モードを使用する Web エージェントとポリシー サーバの通信
プリフォーク モードの Apache ベース Web サーバがリクエストを受信すると、Web サーバは子プロセスを生成してポリシー サーバと通信します。受け取るリクエストが多いほど、それらを処理するためにスポーンされる子プロセスが多くなります。Apache ベースの Web サーバによって生成された各子プロセスは、それぞれ独立してポリシー サーバに接続します。
以下の図では、このプロセスについて説明します。

Apache ベースの Web サーバの場合は、(httpd.conf ファイルの) MaxClients パラメータの値によって、Web サーバで生成される子プロセスの数が決まります。Apache ベースの Web サーバの親プロセスによって子プロセスが生成されると、子プロセスはポリシー サーバへの初期接続を開始します。
Web エージェントの数と Web エージェント プロセスの数の間には重要な違いが存在します。各 Web エージェントにはそれ自身の Web サーバ インスタンスが必要です。たとえば、IIS Web サーバは単一のインスタンスとしてのみ動作するので、IIS Web エージェント数は IIS Web サーバ数と同じです。他のタイプのサーバの場合、1 つの物理 Web サーバ内の異なるポートで複数のサーバ インスタンスがリスニングすることが可能です。
Apache ベースの Web サーバからポリシー サーバに対して開かれるソケットの最大数は、MaxClients パラメータの値に Web エージェント プロセスの数を乗算した数です。たとえば、サーバの MaxClients パラメータの値が 150 に設定され、5 つの Web エージェント プロセスがある場合、開くことができるソケットの最大数は 750 です。
マルチプロセス Web サーバの使用は、
Single Sign-On
環境のポリシー サーバに対する Web エージェント プロセスの割合に影響します。制限要因は、多くの場合に毎秒のトランザクション数ではなく、Web エージェント プロセスとポリシー サーバの間の接続数になります。Web エージェントを展開する前に、リクエストを受信するポリシー サーバが、関連する Web サーバが開くことができる接続の最大数を処理できることを確認します。