Mailing-List: contact users-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@directory.apache.org
Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates
 209.85.212.178 as permitted sender)
Message-ID: <54D3BE64.1000708@gmail.com>
Date: Thu, 05 Feb 2015 20:03:00 +0100
From: =?UTF-8?B?RW1tYW51ZWwgTMOpY2hhcm55?= <elecharny@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: users@directory.apache.org
Subject: Re: [ApacheDS] groupofnames search is slow
References: 
 <CAKahxWGLiCG+cnt5Q8GnUJBEUWBOSMOq05TaLXk3p==uB-Po2g@mail.gmail.com>
In-Reply-To: 
 <CAKahxWGLiCG+cnt5Q8GnUJBEUWBOSMOq05TaLXk3p==uB-Po2g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Le 04/02/15 12:53, John Peter a écrit :
> Hi,
>
> I'm using apacheds 2.0.0 M_19
>
> ApacheDS has 11 group entries and some of them have 26 000 member
> attributes.
>
> I'm using a qucik search via apache directory studio:
> (&(member=uid=john,uid=1.2.246.1.1.1111.10.0,ou=users,dc=test,dc=fi)(objectClass=groupOfNames))
> Using a stopwatch I can see a 5 second delay before the result is visible.
>
> Some other queries perform instantaneously.
> Below is a snipet from the apacheDS log. It shows the search operation took
> only 7070312ns or 7ms. After that apacheDS does something and the next log
> entry is 5 seconds later.
>
> Any idea's what is happening?

Ok, I can reproduce the pb.

If I do a search with

(member=uid=john,uid=1.2.246.1.1.1111.10.0,ou=users,dc=test,dc=fi)

as a filter, it takes only 400ms, and I tested it with 32 000 members in
the entry.

If I add (objectClass=groupOfNames) it takes 14 seconds.

Two things here :
- first, you can do the search omitting the (objectClass=groupOfNames),
because the 'member' attribute is only used by this class, unless you
have created an ObjectClass that uses the 'member' attribute
- second, we should be able to speed up the search when the objectClass
is used in the filter. It seems that we don't evaluate properly the
number of candidates the (member=XXX) part is returning. This is clearly
a bug and need to be fixed.