Optimizing CA Siteminder Performance
- Understand the Agent connectivity to Policy Server
- How Threading in Policy Server Works
- Troubleshooting methods
- Cache management.
Understand the Agent connectivity to Policy Server
- The Web Agent opens the TCP connection to the Policy Server (default:20 )
- Policy Server closes the connection and has the following parameter
- Max Connection
- Idle Timeout setting
- Individual sockets are synchronous connections
- When Web Agent Make a request to the policy server, that socket connection is “busy” until the Policy Server responds
- WebAgent establish an communicates with the Policy server using secure channel
- Timeouts are governed by HCO parameter RequestTimeOut. Default value is 60 seconds
- Webagent make request to Policy Server using API calls
Max thread setting :20
- Policy server accepts all the Incoming connections from Webagent and put them in the Queue.
- On the other end of the queue worker threads take the item off the queue and go to the LDAP Directory Server, retrieve items from the policy store cache / user directory etc
- Similar to the Agent socket request, the worker thread will continue handling the request until it is complete.
- For example, if the worker threads need to do an isAuthenticate() call, it will go out to the LDAP directory server. The worker thread will be blocked until the ldapsearch is complete.
Cause of Slowness
So to find out why the policy server is slowing down? it could be because of the two reason.
- Too many incoming request to Queue.
- Response time from the user directory/policy store to retrieve content
Either one of the above two reasons would cause the Policy Server to queue the request longer than what would be expected
To find out if there is really problem with Policy Server
Execute the following command.
output will be logged to smps.log
[648/2924][Mon Feb 10 2014 21:00:20][CServer.cpp:4600][INFO][sm-Server-02000] System Statistics [648/2924][Mon Feb 10 2014 21:00:20][CServer.cpp:4617][INFO][sm-Server-02020] Thread pool limit: 8 [648/2924][Mon Feb 10 2014 21:00:20][CServer.cpp:4637][INFO][sm-Server-02030] Thread pool: Msgs=10051 Waits=10048 Misses=19720 Max HP Msg=1 Max NP Msg=2 Current Depth=0 Max Depth=2 Current High Depth=0 Current Norm Depth=0 Current Threads=3 Max Threads=3 [648/2924][Mon Feb 10 2014 21:00:20][CServer.cpp:4645][INFO][sm-Server-02040] Connections: Current=1 Max=12 Limit=256 Exceeded limit=0
Monitor the current depth parameter if its keeps growing over time and not decreasing then there could be problem which would cause an outage.
Use SMTRACE Tool to find out the whether the Queue depth causing the issue.
If the Current Depth keeps increasing then possibly to reason
- Load has increased or
- The backend stopped responding or cannot handle it.
- Minimize custom / third party coding
- Use minimum number of LDAP searches required for user authentication/authorization
- Provide Ldapsearch context as close to the container as possible, instead of the adding the root of the tree.
- Make sure there is not many or Nill ldap referrals.
- Keep Agent connection to Policy server and Policy server connection to user directory in the same network or in faster connection.
- Tune up the user directories
SiteMinder provides several caches that can be configured to maintain copies of recently accessed data (for example, user authorizations) to improve system performance. These caches should be configured to suit the nature of the data in your environment, but may also require periodic manual flushing.
SiteMinder deployments can be configured to maintain the following cache on the Policy Server:
- The User Authorization Cache stores user distinguished names (DNs) based on the user portion of policies and includes the users’ group membership.
SiteMinder also maintains an Agent Cacheon each a SiteMinder Agent machine. The Agent Cache has two components:
- The Agent Resource Cache stores a record of accessed resources that are protected by various realms. This cache speeds up Agent to Policy Server communication, since the Agent knows about resources for which it has already processed requests.
- The Agent User Cache maintains users’ encrypted session tickets. It acts as a session cache by storing user, realm, and resource information. Entries in this cache are invalidated based on timeouts established by the realms a user accesses.
Cache Anonymous user to store anonymous user information in cache, set the value of the CacheAnonymous parameter to yes.
Disclaimer: Content posted here worked for me and may not guarantee success, should be used as reference only and please use it cautiously.