Subject: Grouper Developers Forum
- From: Tom Barton <>
- To: Kathryn Huxtable <>
- Cc: Grouper Dev <>
- Subject: Re: [grouper-dev] Proposal for LDAPPC 1.0.1
- Date: Tue, 18 Dec 2007 13:52:31 -0600
Can you tell whether the Brown approach to the time/space trade-off is likely to yield a similar performance gain as your approach? If there's reason to believe so, it seems a simpler approach, ie, with fewer moving parts.
A few questions regarding the database-in-the-middle approach:
1. Would it be necessary to also build a utility to initialize that database to be a snapshot of current LDAP-resident group information?
2. What about ldappc implementations in which one instance is provisioning a subset of the groups registry to LDAP? Is there an issue with specifying how the middle database should be initialized? How about if two or more ldappc instances are each provisioning disjoint slices of the groups registry?
Kathryn Huxtable wrote:
For ldappc version 1.0.1 I propose that the main changes be in improving performance.
My approach when I was at KU was to create a table in an RDBMS containing group/subject tuples and provision the table instead of LDAP. Since KU provisions everything in LDAP from RDBMS tables, this used KU’s usual provisioning to propagate this data into LDAP and keep it synchronized.
Also, I used more memory than the existing code and pulled an entire group’s subjects into memory and compared it with the RDBMS table and then just made changes. This is a more practical approach to the time/space tradeoff in today’s world where memory is cheap and we want fast performance. The ldappc source makes the opposite decision and, to the authors’ credit, documents it.
Brown’s approach has been very similar in terms of time/space, but they directly query LDAP and make the changes there. There are some implementation differences between my KU code and Brown’s, but the concepts are congruent and the performance enhancement similar.
My experience at KU was that although querying LDAP had good performance for groups, querying for memberships had very poor performance. It’s possible that KU’s LDAP was out of cache space for the people branch. KU was having some LDAP performance problems at the time. Since KU always masters everything in an RDBMS anyway, this made the choice of a database table with a separate synchronization with LDAP a natural approach.
I’m willing to do this either way, with or without a database table. I’ll change the comparison and update code to reflect either my approach or, with Brown’s permission, Brown’s approach, depending on which one gives the best performance when abstracted and tested against some random test data sets.
If I use a database table, my plan is to embed a Derby database by default but allow the user to configure any alternate database of their choice. That way, this could still be adapted to KU’s use or could be used to feed Sun Identity Manager or Novell Identity Manager (where used) from the table, providing good integration with commercial IDMS products.
Has anyone else had “bad” performance querying their people branch for subjects with particular isMemberOf values. (Or any other indexed attribute other than RDN?)
What do people think? And if this sounds good, with or without a database table?
PS: For ldappc version 2.0 I propose a more extensive refactoring of the code to support multiple plugins to provision things other than LDAP. I might actually propose that the name of the product be changed to rbacpc (role based access control provisioning connector). I have ideas about this, but let's get the work started on ldappc 1.0.1 first.
- Proposal for LDAPPC 1.0.1, Kathryn Huxtable, 12/18/2007
- Re: [grouper-dev] Proposal for LDAPPC 1.0.1, Tom Barton, 12/18/2007
Archive powered by MHonArc 2.6.16.