Poor performance associated with CA SiteMinder® data stores, especially user directories, is one of the most common reasons for poor CA SiteMinder® performance. Data tier performance typically correlates with two general areas:
A performance strategy includes:
Note: The sustained and peak rates at which user authentication and authorization occur can be calculated.
The Policy Server interacts with the data tier using standard protocols. If your directory servers and databases are tuned to maximize performance with their normal clients, then these modifications can translate into improved CA SiteMinder® performance.
Note: See your vendor-specific documentation for tuning guidance.
There are several general considerations to improving CA SiteMinder® performance as it relates to the performance of your user directories. Examine the following areas:
The system resources available to the user directory directly correlates to CA SiteMinder® performance. If the user directory is operating at a high level of utilization, then no amount of CA SiteMinder® tuning can improve performance.
Be sure that the system hosting the user directory is not degrading performance due to:
Consider the following if you are planning to implement SSL in your CA SiteMinder® environment:
When you configure user directory connections in the Administrative UI, consider using static IP addresses rather than hostnames. Although the time the Policy Server takes to resolve hostnames is negligible, using static IP addresses removes Domain Naming Services (DNS) dependencies.
Making sure that CA SiteMinder® can efficiently search users directories directly correlates with performance. Consider the following:
Note: Microsoft recommends using the objectCategory attribute instead of objectClass. Failing to index the objectClass attribute in Active Directory can result in significant performance degradation.
Note: See your vendor-specific documentation for more information about indexing.
Note: If you are unable to optimize the query, set the maximum search results parameter to limit large result sets from degrading overall performance.
Replication can degrade performance in the following situations:
The redirection results in additional time spent on the authentication step, and the master-replica may not be able to accommodate the rate at which writes occur.
The Policy Server performs a series of services to authenticate and authorize users. These services result in number of reads and writes, collectively known as requests, to a user directory. A significant contributing factor to CA SiteMinder® performance is determining whether your user directories can handle this workload during sustained and peak periods of operation.
The following general factors influence CA SiteMinder® performance:
In turn, the rate at which the Policy Server makes user directory requests to process the operations fluctuates. Some periods generate relatively few user directory requests, while others generate more.
The sustained user directory search rate represents a period during which the Policy Server makes an average number of user directory requests to service an average number of operations.
The following graphic illustrates:
We recommend using the following guidelines to estimate the load under which your user directories have to operate. Once you have estimated the load, you can use any standard tool to create the load on the directory and track the results.
Note: Many factors can contribute to failing to achieve the required numbers. See your vendor–specific documentation for tuning guidance.
Estimating the number of user directory requests that the Policy Server must make to service authentication and authorization requests requires specific information. Gather the following before beginning a user store capacity plan:
Note: A capacity planning effort can help you identify metrics related to authentication load, authorization load, and sustained and peak levels of user activity.
Estimating a sustained user directory search rate is the process of determining:
Complete the following steps to estimate the sustained user directory search rate:
A Policy Server makes a number of user directory requests to service each authentication request. Some of the user directory requests are required, while others can be avoided.
Estimate the number of Policy Server requests that each authentication creates using the following guidelines:
(Required) Two searches to authenticate each user:
(Optional) Additional searches may be required depending on how you design policies and if you decide to enable Password Services:
Note: For more information about configuring rules, see the Policy Server Configuration Guide. For more information about the relationship a rule has to a CA SiteMinder® policy, see the Policy Server Configuration Guide.
Note: For more information about responses and their relationship to rules, see the Policy Server Configuration Guide.
Note: For more information about Password Services, see the Policy Server Configuration Guide.
The following use cases detail how you can use each guideline to determine the total number of user directory searches the authentication load creates.
Case 1: User Authentication and Directory Requests
A company has:
The company uses the following formula to begin estimating the number of requests the Policy Server sends to the user directory to service the authentication load:
authentication_load * 2 * number_of_user_stores = requests_for_authentication
Specifies the number of daily authentications for the application.
Note: Two (2) is a constant. Authenticating a users results in two requests. One search to identify the user and one bind to verify credentials.
Specifies the number of user stores in the implementation.
Specifies the number of user directory requests that the authentication load creates.
Result: 88,000 * 2 * 1 = 176,000 requests.
The company uses this estimate to determine the total number of user directory requests required to service the daily authentication load.
Case 2: Policy Design and User Directory Requests
A company has configured four policies to protect the application portal, one of which is bound to a rule that fires upon a successful authentication.
The company uses the following formula to continue estimating the number of requests the Policy Server sends to the user directory to service the authentication load:
authentication_load * (percent_of_policies * number_of_searches) = requests_for_authentication
Specifies the number of daily authentications for the application.
Specifies the total number of enabled policies, represented as a percentage, that are:
Example: Four enabled CA SiteMinder® policies exist. One is bound to an OnAuth rule. This policy generates one user directory search to determine policy membership. Twenty–five percent of the enabled policies fire on authentication and generate one user store search. The remaining policies do not fire during authentication.
Specifies the number of requests that the Policy Server makes to determine if the CA SiteMinder® policy applies to each authenticated user.
Specifies the number of user directory requests that the authentication load creates.
Result: 88,000 * 0.25 * 1 = 22,000 requests
The company uses this estimate to determine the total number of user directory requests required to service the daily authentication load.
Case 3: Responses and User Directory Requests
A company has defined one CA SiteMinder® policy with an OnAuth rule. This policy requires that a common name (cn) attribute response be returned when the policy fires. The company defines a Web Agent response to return this value and binds it to the CA SiteMinder® policy rule.
The company uses the following formula to continue estimating the number of requests the Policy Server sends to the user directory to service the authentication load:
authentication_load * percent_of_policies * number_of_responses_per_policy = requests_for_authentication
Specifies the number of daily authentications for the application.
Specifies the total number of enabled policies, represented as a percentage, that are bound to a specific number of responses that return user attributes.
Example: If there are four enabled policies, and one uses a response to return a user attribute, then twenty–five percent of the policies require a user directory search.
Specifies the number of responses bound to the CA SiteMinder® policy.
Specifies the number of user directory requests that the authentication load creates.
Result: 88,000 * 0.25 * 1 = 22,000 requests
The company uses this estimate to determine the total number of user directory requests required to service the daily authentication load.
Case 4: Password Services and Directory Requests
A company has enabled Password Services for their user store. The company uses the following formula to continue estimating the number of requests the Policy Server sends to the user directory to service the authentication load:
authentication_load * 1 = requests_for_authentication
Represents the number of daily authentications for the application.
Note: One (1) is a constant. Tracking user login details requires one write to the user directory for each authentication.
Represents the number of user directory requests that the authentication load creates.
Result: 88,000 * 1 = 88,000 requests.
The company uses this estimate to determine the total number of user directory requests required to service the daily authentication load.
Case 5: Total Directory Requests for Authentication
A company uses the individual totals from each use case to determine the total number of requests the Policy Server sends to the user store to service the authentication load:
Result: 176,000 + 22,000 + 22,000 + 88,000 = 322,080 requests
The company uses this result and the results based on the authorization load to estimate the sustained rate at which the user store must service Policy Server requests.
A Policy Server makes a number of user directory requests to authorize a user. Some of the user directory requests are required to determine CA SiteMinder® policy membership, while others are dependent on CA SiteMinder® policy design. You can estimate the number of Policy Server requests that each authorization creates using the following guidelines.
Note: This guideline only applies to policies whose membership filter results in one or more user directory requests. For more information about the relationship between CA SiteMinder® policy membership and user directory requests, see Policy Membership and Authorization Requests.
Note: For more information about the relationship between responses and user directory requests, see Responses and Authorization Performance.
The following use cases detail how you can use each guideline to determine the total number of user directory searches the authorization load creates.
Note: The user authorization cache can significantly reduce the number of authorization-related requests to user directories.
Case 1: Policy Membership and User Directory Requests
A company has enabled three policies protect their portal application:
Additionally, the results of a capacity planning effort show that the application has an authorization load of 726,000.
The company uses the following formula to begin estimating the number of requests that the Policy Server sends to the user directory to service the authorization load:
authorization_load x percent_of_policies * number_of_searches = daily_authorization_requests
Specifies the number of daily authorizations for the application.
Specifies the number of enabled policies, represented as a percentage, that may result in the same number of user directory requests to determine CA SiteMinder® policy membership.
Note: The total percentage must equal 100 percent.
Specifies the number of user directory requests that the Policy Server may make to determine CA SiteMinder® policy membership.
Specifies the number of user directory requests to service the authorization request.
Result:
The company uses this estimate to determine the total number of user directory requests required to service the daily authorization load.
Case 2: Responses and User Directory Searches
A company has enabled three policies to protect their portal application, two of which are bound to responses that return user attributes:
The company uses the following to estimate the number of user directory requests that the Policy Server makes to resolve responses that return user attributes:
authorization_load * percent_of_policies * number_of_responses= daily_authorization_requests
Specifies the number of daily authorizations for the application.
Specifies the number of enabled policies, represented as a percentage, that result in the same number of user directory requests because of responses returning user attributes.
Note: The total percentage must equal 100 percent.
Specifies the number of responses bound to the CA SiteMinder® policy.
Specifies the number of user directory requests to service the authorization request.
Result:
The company uses this estimate to determine the total number of user directory requests required to service the daily authorization load.
Case 3: Total Directory Requests for Authorization
The company uses the individual totals from each use case to determine the total number of requests the Policy Server sends to the user directory to service the authorization load:
Result: 1,203,440 + 526,000= 1,729,440 requests
The company uses these result and the results based on the authentication load to estimate the sustained rate at which the user store must service Policy Server requests.
The sustained user directory search rate is based on the total number of operations (authentication load plus authorization load), specifically, when and at what rate these requests occur. The chance that these requests are uniformly spread across your business day is unlikely. Rather, the rate at which these requests occur fluctuates, remaining between the lowest and highest (peak) levels for a sustained period.
Estimating the sustained user directory search rate is the process of identifying:
When estimating the sustained user directory search rate, we recommend using the daily authentication load and authorization load to identify:
Note: We recommend beginning with an evaluation period of 24 hours, broken down into one-hour increments. However, depending on the requirements of your enterprise, you can compare your daily results over a period of weeks or months to gain a better understanding of usage throughout the year.
The following figure is an example of these metrics.
Case: Estimate the Sustained User Directory Search Rate
The company has determined that:
The company uses the following formula to estimate the sustained user store search rate:
(total_user_directory_requests * percentage_of_requests) / number_of_hours / 3600 = sustained_user_directory_search_rate
Represents the daily number of requests the Policy Server makes to the user directory to service authentication and authorization requests.
Represents the percentage of total operations that occur when the system is operating at sustained levels.
Represents the number of hours when the system is operating at a sustained rate.
Represents the number of requests, per second, the Policy Server makes to the user directory to maintain the sustained rate of operation.
Result: (2,051,520 * 0.48) / 5 /3600 = 54.7 user directory requests per second.
The Policy Server makes 54.7 requests, per second, to the user directory when servicing authentication and authorization requests during sustained levels of operation.
The peak user directory search rate is based on the total number of operations (authentication load plus authorization load), specifically, when and at what rate the system is operating at peak levels. Estimating the peak user directory search rate is the process of identifying when the system is servicing the highest level of operations and how these requests translate into user directory searches.
When estimating the peak authorization rate, we recommend using the metrics that you gathered when determining the sustained authorization rate to determine:
The following figure is an example of these metrics:
A company has determined the application results in a total of 888,000 operations per day. These operations result in approximately 2,051,520 user directory searches. Using metrics gathered during a capacity planning exercise, the company has determined that during the single busiest hour, approximately 278,000 operations, or 31 percent of the total operations, occurred.
The company uses the following formula to estimate the peak user store search rate.
(total_user_directory_requests * percentage_of_requests) / number_of_hours / 3600 = peak_authentication_request_rate
Represents the total number of requests the Policy Server sends to the user store.
Represents the percentage of operations that occur when the system is operating at peak levels.
Represents the number of hours in which the system operates at peak levels.
Represents the number of requests, per second, that the Policy Server makes to the user store to maintain the peak authentication rate.
Result: (2,051,520 * 0.31) / 1 / 3600 = 176.6 requests per second.
The Policy Server makes 176.6 requests, per second, to the user directory when servicing authentication and authorization requests during peak levels of operation.
The Policy Server performs a series of services to authenticate and authorize web service request messages. These services result in number of reads and writes, collectively known as requests, to a user directory. A significant contributing factor to CA SiteMinder WSS performance is determining whether your user directories can handle this workload during sustained and peak periods of operation.
The following general factors influence CA SiteMinder WSS performance:
In turn, the rate at which the Policy Server makes user directory requests to process the operations fluctuates. Some periods generate relatively few user directory requests, while others generate more.
The sustained user directory search rate represents a period during which the Policy Server makes an average number of user directory requests to service an average number of operations.
The following graphic illustrates:
We recommend using the following guidelines to estimate the load under which your user directories have to operate. Once you have estimated the load, you can use any standard tool to create the load on the directory and track the results.
Note: Many factors can contribute to failing to achieve the required numbers. See your vendor–specific documentation for tuning guidance.
Estimating the number of user directory requests that the Policy Server must make to service web service requests requires specific information. Gather the following before beginning a user store capacity plan:
Estimating a sustained user directory search rate is the process of determining:
Complete the following steps to estimate the sustained user directory search rate:
A Policy Server makes a number of user directory requests to service each authentication request. Some of the user directory requests are required, while others can be avoided.
Estimate the number of Policy Server requests that each authentication creates using the following guidelines:
(Required) Two searches to authenticate each user:
(Optional) Additional searches may be required depending on how you design policies:
Note: For more information about configuring rules, see the Policy Server Configuration Guide. For more information about the relationship a rule has to a CA SiteMinder® policy, see the Policy Server Configuration Guide.
Note: For more information about responses and their relationship to rules, see the Policy Server Configuration Guide.
A Policy Server makes a number of user directory requests to authorize a user. Some of the user directory requests are required to determine CA SiteMinder® policy membership, while others are dependent on CA SiteMinder® policy design. You can estimate the number of Policy Server requests that each authorization creates using the following guidelines.
Note: This guideline only applies to policies whose membership filter results in one or more user directory requests. For more information about the relationship between CA SiteMinder® policy membership and user directory requests, see Policy Membership and Authorization Requests.
Note: For more information about the relationship between responses and user directory requests, see Responses and Authorization Performance.
Note: The user authorization cache can significantly reduce the number of authorization-related requests to user directories.
The sustained user directory search rate is based on the total number of operations (authentication load plus authorization load), specifically, when and at what rate these requests occur. The chance that these requests are uniformly spread across your business day is unlikely. Rather, the rate at which these requests occur fluctuates, remaining between the lowest and highest (peak) levels for a sustained period.
Estimating the sustained user directory search rate is the process of identifying:
When estimating the sustained user directory search rate, we recommend using the daily authentication load and authorization load to identify:
Note: We recommend beginning with an evaluation period of 24 hours, broken down into one-hour increments. However, depending on the requirements of your enterprise, you can compare your daily results over a period of weeks or months to gain a better understanding of usage throughout the year.
Case: Estimate the Sustained User Directory Search Rate
The company has determined that:
The company uses the following formula to estimate the sustained user store search rate:
(total_user_directory_requests * percentage_of_requests) / number_of_hours / 3600 = sustained_user_directory_search_rate
Represents the daily number of requests the Policy Server makes to the user directory to service authentication and authorization requests.
Represents the percentage of total operations that occur when the system is operating at sustained levels.
Represents the number of hours when the system is operating at a sustained rate.
Represents the number of requests, per second, the Policy Server makes to the user directory to maintain the sustained rate of operation.
Result: (2,051,520 * 0.48) / 5 /3600 = 54.7 user directory requests per second.
The Policy Server makes 54.7 requests, per second, to the user directory when servicing authentication and authorization requests during sustained levels of operation.
The peak user directory search rate is based on the total number of operations (authentication load plus authorization load), specifically, when and at what rate the system is operating at peak levels. Estimating the peak user directory search rate is the process of identifying when the system is servicing the highest level of operations and how these requests translate into user directory searches.
When estimating the peak authorization rate, we recommend using the metrics that you gathered when determining the sustained authorization rate to determine:
A company has determined the application results in a total of 888,000 operations per day. These operations result in approximately 2,051,520 user directory searches. Using metrics gathered during a capacity planning exercise, the company has determined that during the single busiest hour, approximately 278,000 operations, or 31 percent of the total operations, occurred.
The company uses the following formula to estimate the peak user store search rate.
(total_user_directory_requests * percentage_of_requests) / number_of_hours / 3600 = peak_authentication_request_rate
Represents the total number of requests the Policy Server sends to the user store.
Represents the percentage of operations that occur when the system is operating at peak levels.
Represents the number of hours in which the system operates at peak levels.
Represents the number of requests, per second, that the Policy Server makes to the user store to maintain the peak authentication rate.
Result: (2,051,520 * 0.31) / 1 / 3600 = 176.6 requests per second.
The Policy Server makes 176.6 requests, per second, to the user directory when servicing authentication and authorization requests during peak levels of operation.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|