When a CA SiteMinder® Agent intercepts a request sent to a web or application server, the agent makes the following calls to the CA SiteMinder® Policy Server:
Each of the previous calls generates traffic between the agent in the Web Tier, and the Policy Server in the Application Tier. The following settings can help you adjust the performance of the Web Tier:
The shaded items shown in the following illustration contain settings that affect the performance of your Web Tier:
CA SiteMinder® agents can be installed on a number of supported web and application servers. The performance of the hosting server determines the performance of the CA SiteMinder® web tier. The following items affect how your web server performs with CA SiteMinder®:
The following factors influence CA SiteMinder® Web Agent performance:
If too few web servers are available to handle the number of requests, the following types of problems can occur:
Anticipating the number of requests serviced by each web or application server during peak periods can help you determine the ideal number of web servers for your CA SiteMinder® environment.
Use any of the following methods to estimate the number of requests:
Note: For more information, see the documentation provided by your web server vendor.
When a CA SiteMinder® Agent starts, it opens the number of sockets specified by the MinSocketsPerPort parameter in the Host Configuration Object on the Policy Server. If more requests are received, the Agent adds a specified number of new sockets to the connection pool until the maximum number of sockets is reached. When all sockets used, any additional requests (up to 300) are held in a queue, until one of the following events occurs:
The following illustration describes this process:
The Host Configuration Object on the Policy Server contains the parameters that control the number of sockets used.
Consider increasing the length of time that requests from CA SiteMinder® Agents are held in the Policy Server queue if your network has any of the following conditions:
The RequestTimeout parameter in the Host Configuration Object on the Policy Server controls how long the Agents wait for responses from the Policy Server. If the interval is too short, the requests time out and the user receives an error message.
Note: For more information, see the CA SiteMinder® Policy Server Configuration Guide.
If your capacity planning estimates reveal that the number of user requests per CA SiteMinder® agent exceeds 60 at any given moment (20 requests in process and 40 in the queue), increase the value of the MaxSocketsPerPort parameter.
After increasing the value of the MaxSocketsPerPort parameter in the Administrative UI, verify that the Max Connections setting in the Policy Server Management Console is high enough to accommodate all the Agent processes in your CA SiteMinder® environment. This setting determines the maximum number of connections available to a specific Policy Server.
Note: For multiprocess web servers (such as an Apache-based server in pre-fork mode), you can reduce this number of sockets to one. Because each process uses only a single thread to communicate with the CA SiteMinder® Policy Server, only one socket is required.
When the CA SiteMinder® Agent requires additional sockets from the connection pool during peak loads, the NewSocketStep parameter determines the number of sockets obtained each time.
If the value of the NewSocketStep parameter is set too low, response time during peak periods suffers because the Agent takes extra time to create socket connections.
To help avoid slow response times, use your capacity planning estimates to determine how many requests your Agents handle, and then increase the value of the NewSocketStep parameter accordingly.
The ideal number for this parameter is one large enough to prevent the Agent from spending too much time creating sockets for requests as the load on the web or application server increases.
We recommend experimenting with different settings until you find what works best in your CA SiteMinder® environment.
Note: For multiprocess web servers (such as an Apache-based server in pre-fork mode), you can reduce this number of sockets to one. Because each process uses only a single thread to communicate with the CA SiteMinder® Policy Server, only one socket is required.
When a CA SiteMinder® Agent starts, it opens the number of sockets specified by the MinSocketsPerPort parameter in the Host Configuration Object on the Policy Server. These sockets maintain a constant connection to the Policy Server.
For most types of web and application servers (including Apache-based servers in worker mode), we recommend leaving this parameter at its default setting. Increasing this parameter occupies additional sockets unnecessarily by leaving them open even when the Agent is not receiving any requests for resources.
Note: For multiprocess web servers (such as an Apache-based server in pre-fork mode), you can reduce this number of sockets to one. Because each process uses only a single thread to communicate with the CA SiteMinder® Policy Server, only one socket is required.
The type web server that you are using determines the relationship between the socket-allocation parameters on the Policy Server.
Since single-process multiple-threaded web servers operate differently than multiple-process single-threaded web servers, the allocation of sockets on your Policy Servers differs for each type of web server.
Note: See the documentation from the vendor of your web server to determine its type.
The following illustration describes the formula for single-process, multiple-threaded web servers:
The following illustration describes the formula for multiple-process, single-threaded web servers:
The following illustration describes the formula for multiple-process, multiple-threaded web servers:
Use any of the previous formulas as guides when adjusting your socket settings.
CA SiteMinder® Agents multiple caches and configuration parameters that you can use together to reduce the amount of traffic between your Agents and Policy Servers. Generally, these settings are most efficient in CA SiteMinder® environments where the policies and URIs usually remain static.
The CA SiteMinder® Agent searches the following caches for the information it needs before contacting the CA SiteMinder® Policy Server:
Because retrieving information from a cache is quicker than contacting the Policy Server, performance improves. The following illustration describes this process:
Each CA SiteMinder® Agent uses a resource cache to store the following information it receives from the Policy Server temporarily:
The Agent searches the resource cache to determine if a resource is protected before contacting the Policy Server. If the resource exists in the cache, traffic to the Policy Server is reduced because the Agent does not make an IsProtected call to the Policy Server.
Two Agent configuration parameters affect the resource cache. Consider the following as you plan your CA SiteMinder® deployment:
We recommend basing the timeout interval of the Agent resource cache on the results of your capacity planning tests. A timeout interval that is too small limits the effectiveness of the resource cache. The value of the ResourceCacheTimeout parameter in your Agent configuration determines the timeout interval of the resource cache.
We recommend using a resource cache that is 10 percent larger than the largest number of URIs that you expect users to request. If you are protecting an application that uses dynamic URLs (such as URLs with query strings) consider using the IgnoreQueryData parameter instead of adjusting the size of the resource cache. The value of the MaxResourceCacheSize agent configuration parameter determines the size of the resource cache.
Note: For more information, see the Web Agent Configuration Guide.
If you want to protect applications that use URL query strings, you can still take advantage of the resource cache by configuring the Web Agent to ignore the data in the query string. When the query string data is ignored, the truncated URL is stored in the resource cache. Query strings are ignored by setting the value of the IgnoreQueryData parameter in your Web Agent configuration.
Important! Do not enable this setting if you have policies which depend on URL query data.
The following table shows how ignoring the query strings in a URL determines whether the items from resource cache are used, or if the Web Agent contacts the Policy Server instead:
|
Requested URL with query string |
Truncated URL |
Cached |
Policy Server Contacted |
|---|---|---|---|
|
/exampleapplication/page1.html |
/exampleapplication/ |
No |
Yes |
|
/exampleapplication/page1.html |
|
Yes |
No |
|
/exampleapplication/page2.html |
/exampleapplication/ |
No |
Yes |
Note: For more information, see the Web Agent Configuration Guide.
Each CA SiteMinder® Agent uses a session cache to store the authentication information of users whom the Policy Server has already authenticated.
The Agent searches the session cache to determine whether a user is authenticated before contacting the Policy Server for authentication. The session cache improves performance by reducing the number of authentication calls to the Policy Server.
The authentication for a user ends when any of the following events occur:
Authentication information is removed from the session cache and discarded.
Each CA SiteMinder® Agent uses an authorization cache to store the authorization identification of users whom the Policy Server has already authorized.
The Agent searches the authorization cache to determine whether a user is authorized before contacting the Policy Server for authorization. The authorization cache improves performance by reducing the number of authorization calls to the Policy Server.
The authorization for a user ends when any of the following events occur:
The authorization identification is removed from the cache and discarded.
A combination of Policy Server settings and agent configuration parameters control the session cache and authorization cache. Use the results of your capacity planning as a guide to determine the best values for the following settings in your CA SiteMinder® deployment:
We recommend setting the session timeouts as follows:
Policy Server settings determine the timeout intervals.
Note: For more information, see the CA SiteMinder® Policy Server Configuration Guide.
Base the size of this cache on the number of users that you expect to access a resource for a sustained period during the session timeout interval. Include users who logout and log back in during the session timeout period in your sizing estimate. Do not include users whom you expect to make relatively few requests in your sizing estimate (because these users have a small effect on the session cache and authorization cache). A Web Agent configuration parameter named MaxSessionCacheSize determines the size of both the session cache and the authorization cache.
Note: For more information, see the Web Agent Configuration Guide.
The anonymous authentication schemes offered by CA SiteMinder® do not provide access control to resources that they protect. Anonymous authentication schemes allow the following for unidentified users on your network:
When users request resources protected by an anonymous authentication scheme, the Policy Server assigns a Global Unique Identifier (GUID), and stores it in the browser of the associated user. CA SiteMinder® uses this GUID to identify the user.
If you plan to use an anonymous authentication scheme, implementing the following items can improve performance in your CA SiteMinder® environment:
Using separate web severs and Web Agents for anonymous users keeps the caches on the other web servers that service requests for the protected resources from being flushed too often.
Note: For more information, see the Web Agent Configuration Guide.
The following parameters also affect Web Agent performance:
CA SiteMinder® Agents contact the Policy Server regularly to receive any updated policies or encryption keys. The time interval for contacting the Policy Server can be adjusted by changing the PSPollInterval agent configuration parameter.
Increasing the time interval can reduce unnecessary traffic between the Agents and the Policy Server. Consider increasing the interval when your CA SiteMinder® environment has any of the following characteristics:
Note: For more information, see the Agent Configuration Guide or Agent Guide for your Agent.
Important! Increasing the PSPollInterval parameter also affects how quickly the Agents enforce CA SiteMinder® policy changes. For example, suppose you change a Policy to revoke access for a terminated employee at 10:30, and your PSPollInterval parameter has a value of 3600 (the number of seconds in an hour). The Web Agents would not enforce the changed policy until as late as 11:30.
If the resources you want to protect with CA SiteMinder® contain many images or files that you do not want to protect, you can reduce traffic between your Web Agents and Policy Servers by configuring the Web Agent to ignore certain file extensions.
Performance improves because the Web Agent does not make the following calls to the Policy Server:
Requests for the associated resources are passed directly to the web server and the user is granted access.
Identifying the resources you want to protect first can help you determine which file extensions, if any, you want your Web Agents to ignore.
Add any file extensions you want to ignore are to the IgnoreExt parameter of your Web Agent configuration.
Note: For more information, see the Web Agent Configuration Guide.
If you want to leave the resources in certain subdirectories unprotected, you can configure the Web Agent to ignore certain uniform resource identifiers (URI).
For example, if each of your web servers has a subdirectory named pictures, and you want to leave those directories on protected, you can set the IgnoreURL parameter in your Web Agent configuration.
Performance improves because the Web Agent does not make the following calls to the Policy Server:
Requests for the associated resources are passed directly to the web server and the user is granted access.
When you have multiple CA SiteMinder® Agents and Policy Servers, dynamic load balancing reduces latency and improves throughput because the Agents distribute requests among all the Policy Servers. Dynamic load balancing gives the Agents faster access to Policy Servers and more efficient authentication and authorization.
CA SiteMinder® provides software-based failover and load-balancing of their communication with multiple Policy Servers. The EnableFailover parameter of the Host Configuration Object uses one of the following values to determine how Web Agent connections are handled:
Note: For more information, see the CA SiteMinder® Policy Server Configuration Guide.
CA SiteMinder® also supports the use of hardware load balancers to provide high performance dynamic load balancing of connections between CA SiteMinder® Agents and Policy Servers. When configured to expose multiple Policy Servers through a virtual IP address, hardware load balancers handle distribution of load between all Policy Servers associated with that virtual address. Because the Agent does not need to handle failover or load balancing, set the EnableFailover parameter to yes to disable CA SiteMinder® load balancing. Configure only the VIP or VIPs that expose groups of Policy Servers in the Host Configuration Object.
CA SiteMinder® Agents running on multi-threaded web and application servers (such as Sun Java System, IIS, an Apache-based server in worker mode, or WebSphere Application Server), open the minimum number of sockets to a Policy Server at startup.
If you configure your environment for failover or load-balancing between Policy Servers, then the Agent opens the minimum number of sockets to each Policy Server at startup. Connections to a load-balanced Policy Server occur in the same way, although fewer sockets are opened to each Policy Server, because each is getting only half of the total requests.
If configured for failover, and an error occurs between the Agent and the primary Policy Server, then connections to the failover Policy Server are used. Failover occurs per service, so there could be active connections to both the primary and the failover Policy Servers at once. Once the primary Policy Server comes back up, the sockets opened to the failover server remain. All new sockets are opened to the primary Policy Server.
A CA SiteMinder® Agent running on a multi-process web or application server (such as an Apache-based server running in pre-fork mode) opens the same number of connections to all configured Policy Servers, regardless of whether failover has occurred or not.
When failover occurs, it happens independently for each child, because each child process has its own connections to the Policy Server. This results in a 500 error for each socket as failover takes place. After the primary Policy Server comes back up, the sockets opened to the failover server remain open. All new sockets are opened to the primary Policy Server.
Each CA SiteMinder® agent requires its own web server instance. IIS web servers, for example, operate using a single instance on the computer on which is it installed. The number of IIS agents equals the number of IIS web servers.
For other web servers that support multiple instances per computer, you can install and configure one CA SiteMinder® agent for each instance. For example, you could have one computer that runs three separate web server instances. Each instance has its own agent. Therefore, one computer operates three CA SiteMinder® agents.
The following illustration shows an example:
For Apache web servers, the following multi-processing modules (MRMs) affect how the CA SiteMinder® agent processes connect to the Policy Server:
Creates child processes to handle additional requests.
Obtains additional threads from the connection pool to handle additional requests.
Apache-based web servers in worker mode use threads to handle connections to the CA SiteMinder® Policy Server. Threads are obtained from a connection pool as needed to create additional connections to the Policy Server during heavy loads.
The following illustration describes this process:
When an Apache-based web server in pre-fork mode receives a request, the web server spawns a child process to communicate with the CA SiteMinder® Policy Server. When more requests are received, more child-processes are spawned to handle them. Each child process spawned by the Apache-based web server has its own independent connections to the CA SiteMinder® Policy Server.
The following illustration describes this process:
For Apache-based web servers, the value of the MaxClients parameter (in the httpd.conf file) determines the number of child processes spawned the web server. When a parent process from an Apache-based web server spawns a child process, the child process opens an initial connection to the CA SiteMinder® Policy Server.
An important distinction exists between the number of Web Agents, and the number of Web Agent processes. Each Web Agent requires its own web server instance. IIS web servers, for example, only operate as a single instance, so the number of IIS Web Agents equals the number of IIS web servers. For other types of servers, it is possible to have multiple server instances listening on different ports within one physical web server.
The maximum number of sockets opened from an Apache-based web server to a CA SiteMinder® Policy Server equals the value of the MaxClients parameter multiplied by the number of Web Agent processes. For example, if the value of the MaxClients parameter of your server is set to 150, and you have five Web Agent processes, then the maximum number of possible sockets opened is 750.
Using a multiprocess web server affects the ratio of Web Agent processes to Policy Servers in your CA SiteMinder® environment. The limiting factor often becomes the number of connections between the Web Agent processes and the Policy Server, not the number of transactions per second.
Before deploying Web Agents, verify that the CA SiteMinder® Policy Servers receiving the requests can handle the maximum number of connections that the related web servers could open.
|
Copyright © 2013 CA.
All rights reserved.
|
|