David Coutadeur wrote: > Hello, > > I have worked with Soisik on this particular topic. > As you mentionned, in many cases we can just query directly the group. > In our particular scenario, the software only allows one request for getting > the mails of the users present in the dynamic group.
Have you already tried using the deref control to return a mail attribute instead? > > Thus I think it would be great to have a server solution (if possible in > 2.6), especially if dynlist is officially the memberof replacement. > > Regards, > > David > > > > Le 25 juillet 2022 19:38:52 GMT+02:00, Shawn McKinney <smckin...@symas.com> a > écrit : > > > On May 23, 2022, at 3:10 AM, Soisik Froger > <soisik.fro...@worteks.com> wrote: > > I've just sent you sample slapd.conf and a data ldif that illustrate > the long query time on large database. Thank you very much to take a look at > this ! > > > Hi Soisik, > > I've completed a review/test of dynlist, following your excellent example > as sent off list. > > Here are my findings… > > As a baseline, here’s an example of a 'normal' search across a well > populated user tree: > > # time ldapsearch -x -LLL -H ldap://m01:389 -D "dc=example,dc=com" -W -s > sub -b 'ou=people,dc=example,dc=com' "(cn=load01-TEST1-*)" | grep dn: | wc -l > 17470 > > real 0m0.191s > user 0m0.128s > sys 0m0.132s > > Compared with performing a search of the memberof attribute, generated by > dynast. This pulls back the members of a large group (about 25K members): > # time ldapsearch -x -LLL -H ldap://m01:389 -D "dc=example,dc=com" -W -s > sub -b 'ou=people,dc=example,dc=com' > "(memberof=cn=load01-test1-2,ou=groups,dc=example,dc=com)" | grep dn: | wc -l > 23869 > real 4m6.167s > user 0m2.289s > sys 0m2.037s > > That's 4 minutes to search across 100K users. The other search took < 200 > ms. > > As you (and others) have pointed out, there's a significant performance > penalty for searching attributes generated by dylist. > > It's possible that we can get modest improvements within a 2.7 timeframe. > Unfortunately, we don't anticipate being able to get it back into range of a > 'normal' search. > > So, that gets us into looking at mitigation. One approach, focus on what > the client does. For example, instead of searching across the user tree for > membership to a particular group, it's far more efficient to just pull back > that list from the group entry itself. > > This is a technique that of course we’re already familiar with. I bring > it up here for the sake of argument. > > The question: can we sidestep the memberOf performance problems by > focusing on the the client? > > Or, is there a usecase that I've missed for which there's no remedy? > > Thanks > > — > Shawn > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
