As I have mentioned in my previous post, I was in Bangkok last week to help in conducting a Performance Test for a Single Sign-On and Identity Management project for a local bank.
The user complained about slowness when trying to log into Access Manager. He noticed that, at times, it takes a user 4 minutes to login to Access Manager.
From our analysis, this only happens after a long period of inactivity on Access Manager. The technical explanation is due to the connections dropped by the Firewall that sits in-between Access Manager and Directory Server.
When a connection is dropped by the Firewall, the Access Manager is not aware. Thus when a user attempts to login to Access Manager after a long period of inactivity, he will need to wait around 4 minutes. This is the approximate time taken for the Access Manager to wait for TCP timeout and retry with a new connection to Directory Server.
The easiest and most commonly used technique to resolve this issue is to configure the Firewall not to drop any connection from Sun Access Manager to Sun Directory Manager. However, the customer has indicated that the Nokia Firewall cannot be configured as such.
The workaround is to set a parameter in Access Manager. This ensures that the connections from Access Manager are restarted even before the Firewall attempts to drop any inactive connection.
The easiest and most commonly used technique to resolve this issue is to configure the Firewall not to drop any connection from Sun Access Manager to Sun Directory Manager. However, the customer has indicated that the Nokia Firewall cannot be configured as such.
The workaround is to set a parameter in Access Manager. This ensures that the connections from Access Manager are restarted even before the Firewall attempts to drop any inactive connection.
/**
* The following properties can be used when a Load Balancer/Firewall
* is in between the agents and the Directory Server and the persistent
* search connections are dropped by them when TCP idle timeout happens.
*
* These properties make sure that the persistent searches restart
* in such cases when the connections are dropped.
*
* The property 'com.sun.am.event.connection.idle.timeout' specifies
* timeout value in minutes after which the persistent searches will be
* restarted. Ideally, this value should be lower than the Load Balancer/
* Firewall TCP timeout, to make sure that the persistent searches are
* restarted before the connections are dropped. A value of '0' indicates
* that these searches will not be restarted. By default the value is '0'
* Note: only the connections that are timed out will be reset.
*/
com.sun.am.event.connection.idle.timeout=60
No comments:
Post a Comment