Pinned topic Registry Direct API in a multithreaded web application degrades performance
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 120000981E1 PostACCEPTED ANSWER
Re: Registry Direct API in a multithreaded web application degrades performance2013-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.