データ層のパフォーマンス

目次
casso126jjp
目次
2
Single Sign-On
データ ストア(特にユーザ ディレクトリ)に関連する貧弱なパフォーマンスは、
Single Sign-On
のパフォーマンスを低下させる最も一般的な原因の 1 つです。データ層のパフォーマンスは、通常以下の 2 つの一般的な領域と相関します。
  • データ層自体。正しく調整されていない、またはシステム リソースが十分でないユーザ ディレクトリは、
    Single Sign-On
    のパフォーマンスを低下させる場合があります。
  • ユーザ ディレクトリが動作する容量。
    Single Sign-On
    認証および許可サービスによって、ユーザ ディレクトリへの複数の読み取りおよび書き込み(リクエストと総称される)が生じます。ユーザ ディレクトリ自体で容量計画作業を実行して、ユーザ ディレクトリが
    Single Sign-On
    作業負荷を処理できることを確認します。
パフォーマンス戦略には以下が含まれます。
  • データ層自体が、貧弱なパフォーマンスの主な原因ではないことを確定する。
  • Single Sign-On
     が指定された期間に処理する必要がある認証および許可の数を特定する。
    : ユーザ認証および許可が発生する持続レートおよびピーク レートを算出できます。
  • 各ユーザ認証および後続の許可によって作成されるユーザ ディレクトリ リクエストの数を概算する。
データ層ガイドライン
ポリシー サーバは標準プロトコルを使用してデータ層と対話します。パフォーマンスを最大化するようにディレクトリ サーバおよびデータベースを標準クライアントで調整すると、これらの変更によって
Single Sign-On
のパフォーマンスが向上する場合があります。
: 調整の詳細については、ベンダー固有のマニュアルを参照してください。
Single Sign-On
 のパフォーマンスの向上については、ユーザ ディレクトリのパフォーマンスに関連するため、いくつかの一般的な考慮事項があります。以下の領域を検査します。
  • ユーザ ディレクトリに使用できるシステム リソースおよびそれらのリソースに対して競合する可能性がある外部リソース
  • Secure Socket Layer の使用
  • Single Sign-On
    がユーザ ディレクトリを検索できる効率性
  • スタティック IP アドレスの使用
  • レプリケーションの使用
システム リソース
ユーザ ディレクトリに使用できるシステム リソースは、
Single Sign-On
のパフォーマンスと直接相関します。ユーザ ディレクトリが高い使用率レベルで動作している場合、
Single Sign-On
を調整してもパフォーマンスを向上できません。
ユーザ ディレクトリをホストするシステムが、以下によってパフォーマンスを低下させないことを確認してください。
  • 遅い CPU または I/O システム
  • メモリの不足
  • 正しく設定されていないバッファ キャッシュ
  • ディスク領域不足または断片化
Secure Socket Layer およびユーザ ディレクトリ
Single Sign-On
 環境への SSL の実装を計画している場合は、以下の点について考慮してください。
  • SSL を介して通信するようにポリシー サーバおよび LDAP ユーザ ディレクトリを設定すると、パフォーマンスが低下します。セキュリティ要件を確認して、SSL が必須であるかどうかを判断します。
  • SSL を設定する場合は、ポリシー サーバとディレクトリ サーバの間に SSL アクセラレータを配置しないでください。さもないと、ポリシー サーバはディレクトリの単一のインスタンスを使用します。これにより、アクセラレータの背後にある複数のユーザ ディレクトリにわたって不整合な書き込みが発生する場合があります。
スタティック IP アドレスおよびユーザ ディレクトリ
管理 UI でユーザ ディレクトリ接続を設定する場合は、ホスト名ではなくスタティック IP アドレスを使用することを検討してください。ポリシー サーバによるホスト名の解決にかかる時間は無視できますが、スタティック IP アドレスの使用によって、DNS (Domain Naming Services)依存関係が除去されます。
ユーザ ディレクトリの検索
Single Sign-On
 が効率的にユーザ ディレクトリを検索できるようにすることは、パフォーマンスと直接相関します。以下の点について考慮してください。
  • ディレクトリ インデックスを使用して
    Single Sign-On
    の検索結果を向上させます。
    • LDAP -- 検索で使用される他のすべての属性に加えて、objectClass 属性にもインデックスを付ける必要があります。
      : Microsoft は objectClass の代わりに objectCategory 属性の使用を推奨しています。Active Directory 内の objectClass 属性にインデックスを付けられないと、パフォーマンスが著しく低下する場合があります。
    • ODBC --
      Single Sign-On
      スキーマ クエリで検索条件として定義されたすべてのフィールドにインデックスを付ける必要があります。
      : インデックス付けの詳細については、ベンダー固有のマニュアルを参照してください。
  • 管理しやすいユーザ グループのセットを返すようにクエリを設計します。
    : クエリを最適化できない場合は、最大の検索結果パラメータを設定して、全体的なパフォーマンスが低下しないように大規模な結果セットを制限します。
  • 標準的な SQL アナライザで ODBC の SQL クエリ方式を最適化します。
レプリケーション
レプリケーションは、以下の状況でパフォーマンスを低下させる場合があります。
  • マスタ レプリカがマスタ スレーブ レプリケーションで書き込みリクエストのみを許可する場合。パスワード サービスでは、通常、各認証のパスワード BLOB 属性の更新が必要です。マスタ レプリカのみが書き込みを処理できる場合、各書き込みリクエストはマスタにリダイレクトされます。
    リダイレクトによって、認証手順でさらに時間がかかるようになり、マスタ レプリカは書き込みが発生するレートに対応できない場合があります。
  • LDAP リフェラルが有効な場合。各リクエストがディレクトリへの複数のリクエストに影響する可能性があるので、LDAP リフェラルによってパフォーマンスが低下する場合があります。
ユーザ ストア容量計画
ポリシー サーバは一連のサービスを実行して、ユーザを認証および許可します。これらのサービスによって、リクエストと総称されるユーザ ディレクトリへの読み取りおよび書き込みが生じます。
Single Sign-On
のパフォーマンスに著しく関与する要因によって、ユーザ ディレクトリが操作の持続期間およびピーク期間にこの作業負荷を処理できるかどうかが決定されます。
以下の一般的な要因が
Single Sign-On
のパフォーマンスに影響します。
  • 合計操作数および持続ユーザ ディレクトリ検索レート -- 合計操作数は、認証および許可リクエストの処理時に、ポリシー サーバが処理する必要があるリクエストの合計数です。これらの操作が発生するレートは営業日を通して変動します。
    同様に、ポリシー サーバがユーザ ディレクトリ リクエストを行って操作を処理するレートは変動します。一部の期間では比較的少数のユーザ ディレクトリ リクエストが生成されますが、その他の期間ではより多くのリクエストが生成されます。
    持続ユーザ ディレクトリ検索レートは、ポリシー サーバが平均数のユーザ ディレクトリ リクエストを行い、平均数の操作を処理する期間を表します。
  • 合計操作数およびピーク ユーザ ディレクトリ検索レート -- アクティビティの持続期間中に、ユーザ アクティビティが急増する場合があります。ピーク ユーザ ディレクトリ検索レートは、ポリシー サーバが最も多くのユーザ ディレクトリ リクエストを行い、最大数の操作を処理する期間を表します。
ユーザ ディレクトリが操作する必要があるロードを概算するために以下のガイドラインを使用することをお勧めします。いったんロードを概算すると、すべての標準ツールを使用してディレクトリでロードを作成し、その結果を追跡できます。
: 多くの要因によって必要数の獲得に失敗する場合があります。調整の詳細については、ベンダー固有のマニュアルを参照してください。
ユーザ ストア容量計画のチェックリスト
ポリシー サーバが認証および許可リクエストを処理するために行う必要があるユーザ ディレクトリ リクエスト数の概算には、特定の情報が必要です。ユーザ ストア容量計画を開始する前に以下の情報を収集します。
  • アプリケーションの日単位の認証総数(認証ロード)。
  • アプリケーションの日単位の許可総数(許可ロード)。
  • ユーザがアプリケーションに対して認証し、保護されたリソースをリクエストする持続期間およびピーク期間。
    : 容量計画作業は、認証ロード、許可ロード、およびユーザ アクティビティの持続レベルとピーク レベルに関連するメトリックの識別に役立ちます。
  • 有効なポリシーの総数。各ポリシーについて、以下の点を判断します。
    • ポリシー メンバシップ フィルタによって 1 つ以上のユーザ ディレクトリ検索が生じるかどうか。
    • ポリシーにバインドされたレスポンスによって 1 つ以上のユーザ ディレクトリ検索が生じるかどうか。
持続ユーザ ディレクトリ検索レートの概算方法
持続ユーザ ディレクトリ検索レートの概算は、以下のことを特定するプロセスです。
  • ユーザ ディレクトリ リクエストの総数は営業日全体でどのように変動するか。
  • 持続期間中にユーザ ディレクトリ リクエストが毎秒どのようにリクエストに変換されるか。
以下の手順を実行して、持続ユーザ ディレクトリ検索レートを概算します。
  1. 認証ガイドラインを使用して、認証ロードが作成するユーザ ディレクトリ リクエスト数を概算します。
  2. 許可ガイドラインを使用して、許可ロードが作成するユーザ ディレクトリ リクエスト数を概算します。
  3. 持続ユーザ ディレクトリ検索レートを概算します。
認証ガイドラインの使用によるディレクトリ検索の概算
ポリシー サーバは複数のユーザ ディレクトリ リクエストを行って、各認証リクエストを処理します。ユーザ ディレクトリ リクエストによっては必須のものがありますが、その他は回避できます。
以下のガイドラインを使用して、各認証が作成するポリシー サーバ リクエスト数を概算します。
(必須)各ユーザを認証する 2 つの検索。
  • ユーザを識別するためのストアごとに 1 つの検索/クエリ
  • ユーザ認証情報を確認するための 1 つの検索/クエリ
(オプション)ポリシーの設計方法に応じて、およびパスワード サービスを有効にする場合は、さらに検索が必要になる場合があります。
  • ユーザが認証されると起動されるルール(OnAuth ルール)にバインドされる各ポリシーの 1 つの検索/クエリ。
  • ユーザ属性を返すレスポンスにバインドされる各ポリシーの 1 つの検索/クエリ。
  • パスワード サービスに対して有効にされたユーザ ストアごとに 1 つの書き込み/更新。パスワード サービスがポリシー ドメイン内のユーザ ディレクトリに適用されない場合、書き込み/更新は必要ありません。
以下のユース ケースでは、各ガイドラインを使用して認証ロードが作成するユーザ ディレクトリ検索の総数を特定する方法を説明します。
ケース 1: ユーザ認証およびディレクトリ リクエスト
ある会社の場合
  • バンキング アプリケーションに 1 つのユーザ ディレクトリを展開しました。
  • 容量計画作業を実行しました。その結果はユーザが 88,000 ログインの認証ロードを作成することを示します。
会社は以下の式を使用して、ポリシー サーバが認証ロードを処理するためにユーザ ディレクトリに送信するリクエスト数の概算を開始します。
authentication_load * 2 * number_of_user_stores = requests_for_authentication
  • authentication_load
    アプリケーションの日単位の認証数を指定します。
    : 2 は定数です。ユーザの認証によって 2 つのリクエストが発生します。ユーザを識別するための 1 つの検索と、クレデンシャルを検証するための 1 つのバインド。
  • number_of_user_stores
    実装内のユーザ ストアの数を指定します。
  • requests_for_authentication
    認証ロードが作成するユーザ ディレクトリ リクエストの数を指定します。
結果
: 88,000 * 2 * 1 = 176,000 リクエスト
会社はこの概算を使用して、日単位の認証ロードを処理するために必要なユーザ ディレクトリ リクエストの総数を判断します。
ケース 2: ポリシー設計およびユーザ ディレクトリリ クエスト
ある会社は、4 つのポリシーをアプリケーション ポータルを保護するように設定しました(その内の 1 つは認証成功時に起動するルールにバインドされています)。
会社は以下の式を使用して、ポリシー サーバが認証ロードを処理するためにユーザ ディレクトリに送信するリクエスト数の概算を続行します。
authentication_load
* (
percent_of_policies
*
number_of_searches
) =
requests_for_authentication
  • authentication_load
    アプリケーションの日単位の認証数を指定します。
  • percent_of_policies
    有効なポリシーの総数をパーセンテージで指定します。有効なポリシーについては以下のとおりです。
    • onAuth ルールにバインドされています
    • 同数のユーザ ディレクトリ検索を作成します
    例:
    4 つの有効なポリシーが存在します。1 つは OnAuth ルールにバインドされています。このポリシーは、1 つのユーザ ディレクトリ検索を生成してポリシー メンバシップを判断します。有効なポリシーの 25 パーセントは認証時に起動して、1 つのユーザ ストア検索を生成します。残りのポリシーは、認証中に起動しません。
  • number_of_searches
    ポリシーが認証された各ユーザに適用されるかどうかを判断するためにポリシー サーバが行うリクエストの数を指定します。
  • requests_for_authentication
    認証ロードが作成するユーザ ディレクトリ リクエストの数を指定します。
結果
: 88,000 * 0.25 * 1 = 22,000 リクエスト
会社はこの概算を使用して、日単位の認証ロードを処理するために必要なユーザ ディレクトリ リクエストの総数を判断します。
ケース 3: レスポンスおよびユーザ ディレクトリ リクエスト
ある会社は、OnAuth ルールを持つ 1 つのポリシーを定義しました。このポリシーでは、起動時に共通名(cn)属性レスポンスが返される必要があります。会社は、この値を返す Web エージェント レスポンスを定義して、それをポリシー ルールにバインドします。
会社は以下の式を使用して、ポリシー サーバが認証ロードを処理するためにユーザ ディレクトリに送信するリクエスト数の概算を続行します。
authentication_load
*
percent_of_policies
*
number_of_responses_per_policy
=
requests_for_authentication
  • authentication_load
    アプリケーションの日単位の認証数を指定します。
  • percent_of_policies
    ユーザ属性を返す特定の数のレスポンスにバインドされている有効なポリシーの総数をパーセンテージで指定します。
    : 4 つの有効なポリシーがあり、その内の 1 つがレスポンスを使用してユーザ属性を返す場合、ポリシーの 25 パーセントにはユーザ ディレクトリ検索が必要です。
  • number_of_responses_per_policy
    ポリシーにバインドされたレスポンスの数を指定します。
  • requests_for_authentication
    認証ロードが作成するユーザ ディレクトリ リクエストの数を指定します。
結果
: 88,000 * 0.25 * 1 = 22,000 リクエスト
会社はこの概算を使用して、日単位の認証ロードを処理するために必要なユーザ ディレクトリ リクエストの総数を判断します。
ケース 4: パスワード サービスおよびディレクトリ リクエスト
ある会社は、ユーザ ストア用のパスワード サービスを有効にしました。会社は以下の式を使用して、ポリシー サーバが認証ロードを処理するためにユーザ ディレクトリに送信するリクエスト数の概算を続行します。
authentication_load
* 1 =
requests_for_authentication
  • authentication_load
    アプリケーションの日単位の認証数を表します。
    : 1 は定数です。ユーザ ログイン詳細の追跡には、認証ごとにユーザ ディレクトリへの 1 回の書き込みが必要です。
  • requests_for_authentication
    認証ロードが作成するユーザ ディレクトリ リクエストの数を表します。
結果
: 88,000 * 1 = 88,000 リクエスト
会社はこの概算を使用して、日単位の認証ロードを処理するために必要なユーザ ディレクトリ リクエストの総数を判断します。
ケース 5: 認証に対するディレクトリ リクエスト総数
ある会社は、各ユース ケースからのそれぞれの合計を使用して、ポリシー サーバが認証ロードを処理するためにユーザ ストアに送信するリクエストの総数を判断します。
  • 88,000 人の一意のユーザおよびそれらのクレデンシャルを識別するための 176,000 のリクエスト
  • OnAuth ポリシーがそれらのユーザに適用されるかどうかを判断するための 22,000 のリクエスト
  • 認証時に共通名属性を返すための 22,000 のリクエスト
  • パスワード ポリシーに対する 88,000 のリクエスト
結果
: 176,000 + 22,000 + 22,000 + 88,000 = 322,080 リクエスト
会社は、この結果および許可ロードに基づく結果を使用して、ユーザ ストアがポリシー サーバ リクエストを処理する必要がある持続レートを概算します。
許可ガイドラインの使用によるディレクトリ検索の概算
ポリシー サーバは、複数のユーザ ディレクトリ リクエストを行ってユーザを許可します。ユーザ ディレクトリ リクエストによっては、ポリシー メンバシップを判断するために必須のものがありますが、その他はポリシー設計によって異なります。以下のガイドラインを使用して、各許可が作成するポリシー サーバ リクエスト数を概算できます。
  • ポリシー ドメイン内の各ポリシーの 1 つの検索/クエリ。
    : このガイドラインは、メンバシップ フィルタが 1 つ以上のユーザ ディレクトリ リクエストをもたらすポリシーにのみ適用されます。ポリシー メンバシップとユーザ ディレクトリ リクエストの関係の詳細については、「ポリシー メンバシップおよび許可リクエスト」を参照してください。
  • ユーザ属性を返すレスポンスにバインドされる各ポリシーの 1 つの検索/クエリ。
    : レスポンスとユーザ ディレクトリ リクエストの関係の詳細については、「レスポンスおよび許可パフォーマンス」を参照してください。
以下のユース ケースでは、各ガイドラインを使用して許可ロードが作成するユーザ ディレクトリ検索の総数を特定する方法を説明します。
: ユーザ許可キャッシュは、ユーザ ディレクトリへの許可関連のリクエスト数を大幅に減らす場合があります。
ケース 1: ポリシー メンバシップおよびユーザ ディレクトリ リクエスト
ある会社は、ポータル アプリケーションを保護する 3 つのポリシーを有効にしました。
  • ポリシー A では、ポリシー メンバシップを判断するために 1 つのユーザ ディレクトリ リクエストが必要です。
  • ポリシー B では、ポリシー メンバシップを判断するために最大 2 つのユーザ ディレクトリ リクエストが必要な場合があります。
  • ポリシー C では、ポリシー メンバシップを判断するために最大 3 つのユーザ ディレクトリが必要な場合があります。
さらに、容量計画作業の結果により、アプリケーションには 726,000 の許可ロードがあることが示されます。
会社は以下の式を使用して、ポリシー サーバが許可ロードを処理するためにユーザ ディレクトリに送信するリクエスト数の概算を開始します。
authorization_load
x
percent_of_policies
*
number_of_searches
=
daily_authorization_requests
  • authorization_load
    アプリケーションの日単位の許可数を指定します。
  • percent_of_policies
    ポリシー メンバシップを判断するために、同数のユーザ ディレクトリ リクエストをもたらす可能性がある有効なポリシーの数をパーセンテージで指定します。
    : パーセンテージの合計が 100 パーセントになる必要があります。
  • number_of_searches
    ポリシー メンバシップを判断するために、ポリシー サーバが行う可能性があるユーザ ディレクトリ リクエストの数を指定します。
  • daily_authorization_requests
    許可リクエストを処理するためのユーザ ディレクトリ リクエストの数を指定します。
結果:
  • ポリシー A -- 792,000 * 0.33 * 1= 261,360 リクエスト
  • ポリシー B および C -- 792,000 * 0.66 * 2= 1,045,440 リクエスト
  • ユーザ ディレクトリ リクエスト総数 - 158,000 + 1,045,440= 1,306,880 リクエスト
会社はこの概算を使用して、日単位の許可ロードを処理するために必要なユーザ ディレクトリ リクエストの総数を判断します。
ケース 2: レスポンスおよびユーザ ディレクトリ検索
ある会社は、ポータル アプリケーションを保護する 3 つのポリシーを有効にしました(その内の 2 つは、ユーザ属性を返すレスポンスにバインドされています)。
ポリシー A は起動時に 1 つのユーザ属性を返します。
  • ポリシー B は起動時に 2 つのユーザ属性を返します。
  • ポリシー C はユーザ属性を返すレスポンスにバインドされていません。
会社は以下の式を使用して、ポリシー サーバがユーザ属性を返すレスポンスを解決するために行うユーザ ディレクトリ リクエストの数を概算します。
authorization_load
*
percent_of_policies
*
number_of_responses
=
daily_authorization_requests
  • authorization_load
    アプリケーションの日単位の許可数を指定します。
  • percent_of_policies
    ユーザ属性を返すレスポンスのために同数のユーザ ディレクトリ リクエストをもたらす有効なポリシーの数をパーセンテージで指定します。
    : パーセンテージの合計が 100 パーセントになる必要があります。
  • number_of_responses
    ポリシーにバインドされたレスポンスの数を指定します。
  • daily_authorization_requests
    許可リクエストを処理するためのユーザ ディレクトリ リクエストの数を指定します。
結果:
  • ポリシー A -- 792,000 * 0.2 x 1= 158,000
  • ポリシー B -- 792,000 * 0.2 x 2= 316,800
  • ポリシー C -- 792,000 * 0.6 x 0= 0
  • ユーザ ディレクトリ リクエスト総数 -- 158,000 + 316,800 + 0= 526,000
会社はこの概算を使用して、日単位の許可ロードを処理するために必要なユーザ ディレクトリ リクエストの総数を判断します。
ケース 3: 許可に対するディレクトリ リクエスト総数
会社は、各ユース ケースからのそれぞれの合計を使用して、ポリシー サーバが許可ロードを処理するためにユーザ ディレクトリに送信するリクエストの総数を判断します。
  • ポリシー メンバシップを解決するための 1,203,440 のリクエスト。
  • レスポンスに関連付けられたユーザ属性を返すための 526,000 のリクエスト。
結果
: 1,203,440 + 526,000= 1,729,440 リクエスト
会社は、この結果および認証ロードに基づく結果を使用して、ユーザ ストアがポリシー サーバ リクエストを処理する必要がある持続レートを概算します。
持続ユーザ ディレクトリ検索レートの概算
持続ユーザ ディレクトリ検索レートは、合計操作数(認証ロードと許可ロード)に基づきます(特に、これらのリクエストが発生する時期およびレート)。これらのリクエストが営業日中に均一に分散される可能性はあまりありません。さらに、これらのリクエストが発生するレートは、持続期間の最低レベルと最高(ピーク)レベルの間で変動します。
持続ユーザ ディレクトリ検索レートの概算は、以下を識別するプロセスです。
  • システムが平均数の操作を処理する持続期間
  • これらのリクエストがどのようにユーザ ディレクトリ検索に変換されるか。
持続ユーザ ディレクトリ検索レートの概算時には、日単位の認証ロードおよび許可ロードを使用して以下を特定することをお勧めします。
  • 合計操作数が 1 日の間に発生するレート
    注:
    1 時間のインクリメントに分割した 24 時間の評価期間で始めることをお勧めします。ただし、企業の要件に応じて、数週間または数か月の期間にわたって日単位の結果を比較し、年間を通じた使用状況を詳細に把握できます。
  • システムが平均数のリクエストを処理する持続期間
  • 持続期間中に発生するリクエストの概数です。
ケース: 持続ユーザ ディレクトリ検索レートの概算
会社は以下を特定しました。
  • アプリケーションの日単位の認証ロードおよび許可ロードによって、約 888,000 の合計操作数が生じます。
  • 合計操作数によって約 2,051,520 のユーザ ディレクトリ リクエストが生じます。
  • システムは、持続レベルで約 5 時間(午前 9:00 - 午後 2:00)動作します。
  • 持続レベルの間、1 時間に約 84,000 の操作が発生します。
  • 約 420,000 (84,000 * 5)の操作または合計操作数の 48 パーセント(420,000/880,000)がこの時間内に発生します。
会社は以下の式を使用して、持続ユーザ ストア検索レートを概算します。
(
total_user_directory_requests
 * 
percentage_of_requests
) / 
number_of_hours
 / 3600 = 
sustained_user_directory_search_rate
  • total_user_directory_requests
    ポリシー サーバが認証および許可リクエストを処理するために、ユーザ ディレクトリに対して行う日単位のリクエスト数を表します。
  • percentage_of_requests
    システムが持続レベルで動作しているときに発生する合計操作数の割合を表します。
  • number_of_hours
    システムが持続レートで動作しているときの時間数を表します。
  • sustained_user_directory_search_rate
    ポリシー サーバが操作の持続レートを維持するために、ユーザ ディレクトリに対して行う毎秒のリクエスト数を表します。
結果:
(2,051,520 * 0.48)/5/3600 = 毎秒 54.7 ユーザ ディレクトリ リクエスト。
ポリシー サーバは、操作の持続レベル中に認証および許可リクエストを処理するときに、ユーザ ディレクトリに対して毎秒 54.7 のリクエストを行います。
ピーク ユーザ ディレクトリ検索レートの概算
ピーク ユーザ ディレクトリ検索レートは、合計操作数(認証ロードと許可ロード)に基づきます(特に、システムがピーク レベルで動作する時期およびレート)。ピーク ユーザ ディレクトリ検索レートの概算は、システムが操作の最高レベルを処理する時期、およびこれらのリクエストがどのようにユーザ ディレクトリ検索に変換されるかを特定するプロセスです。
ピーク許可レートの概算時には、持続許可レートの特定時に得たメトリックを使用して以下を特定することをお勧めします。
  • システムが最も多くの操作を処理する時間帯。
  • この期間に発生する操作の概数。
ケース: ピーク ユーザ ディレクトリ検索レートの概算
ある会社は、アプリケーションによって 1 日あたり合計 888,000 の操作が生じることを特定しました。これらの操作によって約 2,051,520 のユーザ ディレクトリ検索が生じます。会社は容量計画実行中に収集したメトリックを使用して、最繁時の 1 時間に約 278,000 の操作(または合計操作数の 31 パーセント)が発生したことを特定しました。
会社は以下の式を使用して、ピーク ユーザ ストア検索レートを概算します。
(
total_user_directory_requests
 * 
percentage_of_requests
) / 
number_of_hours
 / 3600 = 
peak_authentication_request_rate
  • total_authentication_requests
    ポリシー サーバがユーザ ストアに送信するリクエストの総数を表します。
  • percentage_of_requests
    システムがピーク レベルで動作しているときに発生する操作の割合を表します。
  • number_of_hours
    システムがピーク レベルで動作する時間数を表します。
  • peak_user_directory_request_rate
    ポリシー サーバがピーク認証レートを維持するために、ユーザ ストアに対して行う毎秒のリクエスト数を表します。
結果:
(2,051,520 * 0.31)/1/3600 = 毎秒 176.6 リクエスト。
ポリシー サーバは、操作のピークレベル中に認証および許可リクエストを処理するときに、ユーザ ディレクトリに対して毎秒 176.6 のリクエストを行います。