Grouper Developers Forum

[Tom Barton <>]

Mark,

Although the jndi source adapter does not use connection pooling, your 
statement of problem makes me wonder if other issues are also at play 
here, ie, that these absurdly long times may be the result of more than 
just lack of connection pooling.

Some particulars below...

Mark Weber wrote:
> We've started doing some initial load testing and found that it's pretty 
> slow.  Our initial estimates put a full load of our population into 
> grouper, via the xml-import facility, would take about 8 days.

Could you give some basic facts & stats - what back-end database, how 
large its overall allocation, about how many "large" groups & "small" 
groups in the load, how deeply nested, how many employ non-default 
privileges.

> I think I've narrowed it down to the Subject API.  Specifically the 
> Subject API configured using JNDI/LDAP adapter.  For Instance, the UI 
> takes 74 seconds to load the " All Groups   - Current subjects with 
> [xyz] privilege" page.  It displays the first 50 members and creates a 
> connection, bind, search, result, unbind, and disconnect for each person 
> on the page.  Same with the xml-import.

This is far from the fraction of a second I'm accustomed to seeing it 
take the jndi source adapter to display 50 subjects. I suspect there's 
another factor at play in this example, or perhaps your ldap server 
configuration (ACLs, authentication mechanism, other unknown operational 
params) might produce substantially different connection setup and query 
response times compared to the rather vanilla config of the openldap 
server I use for prototyping.

> So, is there some 
> configuration option that allows for connection pooling within the 
> subject API when it's using LDAP?

Not in this version.

> This is an assumption, but if we used the jdbc source adapter instead, 
> would it use connection pooling and thereby eliminate the problem 
> altogether?

I think it does indeed use connection pooling.

Tom