[Date Prev][Date Next]
RE: subquery performance problem
- To: <firstname.lastname@example.org>, <openldap-software@OpenLDAP.org>
- Subject: RE: subquery performance problem
- From: "OpenLDAP Mailing List" <email@example.com>
- Date: Thu, 18 Oct 2001 11:51:42 -0500
- Content-class: urn:content-classes:message
- Thread-index: AcFX1KJVxGFk2gVMRQedLusYkGI84gAH7grQ
- Thread-topic: subquery performance problem
hitting from cache is fast, but generating the cache goes at about 50
users / second. If I build the cache as "root" if would be much faster,
since I think ACL interpretation is expensive. I'll probably do a dn->
cn hashed DB and access that from my app instead of using LDAP queries
if I can't find anything better.
It seems like there is a lot of wasted overhead in network
communications and transactoin management for n+1 queries for n users.
If I could do a batch operation with a callback I'm sure it would fly.
Is this possible? I don't think so...
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com]
> Sent: Thursday, October 18, 2001 7:59 AM
> To: OpenLDAP Mailing List
> Subject: Re: subquery performance problem
> I've written very similar code for our web-based directory
> client, and it
> takes approximately one second per 1000 users. I'd guess that you're
> either doing it wrong on the client or the server.
> On 10/17/01 11:02 PM -0500 firstname.lastname@example.org wrote:
> > I am making a UI on top of OpenLDAP. When resolving group
> membership, I
> > need to use subqueries in order to get a "cn" view of the list.
> > This is a very big performance problem on big lists, since
> I need one
> > query for each member of the list. With 180 users, this
> takes several
> > seconds at best, and gets worse depending on how I structure ACLs.
> > Is there any smart way to do this without sending so many queries? I
> > built a caching dn->cn function in my application and prefetch data
> > during idles, and that helps out a bit, but I am worried about
> > concurrency, stale data, etc.
> > Thanks!