Topic
1 reply Latest Post - ‏2013-04-17T15:54:36Z by pcalvert
SystemAdmin
SystemAdmin
9855 Posts
ACCEPTED ANSWER

Pinned topic Registry Direct API in a multithreaded web application degrades performance

‏2013-03-03T15:21:07Z |
We are using Registry Direct JAVA APi for our web application which basically has to support
on an average 300-400 concurrent user connections. But we have observed some slowness in response
times as the system load increases.
My question is whether the approach through which we get a handle to the registry is correct or not?

We have a Singleton class that contains the single instance of LdapRegistry. We are using the following method
to get the LdapRegistry instance.

RgyRegistry = LdapRgyRegistryFactory.getInstance() ;

I was just wondering that in case of multithreaded web application, with this single instance of LdapRegistry
can we get good performance in our web app, espacially in cases where multiple threads try to reg the handle at the same time. Is it a good idea to pool a certain number of LdapRegistry instances using some object pool API such as one of those from APACHE.

Also, can this concurrent usage of registry API in a multithreaded web application lead to high CPU utilization?

Can you suggest the best practices related to number of LdapRegistry handles we should create?
Also if it is a best practice to create a singletom class and always keeps single instance of LDAPregistry for the entire application? Will this compromise performance?
  • pcalvert
    pcalvert
    1 Post
    ACCEPTED ANSWER

    Re: Registry Direct API in a multithreaded web application degrades performance

    ‏2013-04-17T15:54:36Z  in response to SystemAdmin

    You could try increasing the number of concurrent connections to LDAP that the RDJ API uses.  By default it is only 16 shared by all threads.  It is set via ldap.max-server-connections.

    Which API methods are you using, perhaps we can try and target configuration or usage to help out?

    If you are not using ldap.auth-using-compare=true (which would only operate with IBM LDAP servers) then there is also a limit on the number of simultaneous binds for authenticating users, set using ldap.max-auth-connections.

    If you have a firewall between the API and the LDAP server which drops idle connections, or your LDAP server is configured to drop idle connections then a TAM 6.1.1 fixpack introduced a new configuration option, ldap.connection-inactivity which will close connections to LDAP if they have not been used for a peroid of time.  If the firewall or LDAP server was dropping a RDJ API connection, then it would likely be considered a LDAP server failure, and failover or recovery would take place, slowing things down.