Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com
 designates 209.85.214.53 as permitted sender)
Message-ID: <52271993.5060303@gmail.com>
Date: Wed, 04 Sep 2013 13:29:23 +0200
From: =?UTF-8?B?RW1tYW51ZWwgTMOpY2hhcm55?= <elecharny@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Search performance potential improvements
References: <5227077D.6030207@gmail.com>
 <CABzFU-cWRg+J5aU6TjcmgXpVAosRcdm3j-sCR3jt-3iFr85HXg@mail.gmail.com>
In-Reply-To: 
 <CABzFU-cWRg+J5aU6TjcmgXpVAosRcdm3j-sCR3jt-3iFr85HXg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Le 9/4/13 1:27 PM, Kiran Ayyagari a écrit :
> On Wed, Sep 4, 2013 at 3:42 PM, Emmanuel Lécharny <elecharny@gmail.com>wrote:
>
>> Hi guys,
>>
>> I just came back from a short week of excellent vacations, and I spent
>> the last two days looking at the search operation.
>>
>> Just before I left, I thought that the entry was cloned for no reason.
>> The fact is that we do modify the entry before returning it, so we must
>> modify a copy of the cached entry, otherwise we can have some really
>> nasty bugs in other parts (the entry is cached, so we can't simply
>> modify it).
>>
>> OTOH, I discovered that we do a costly check in the
>> DefaultSearchEngine.computeResults() method : we check if the search
>> BaseDN is an alias by looking into the Alias index. Not doing this check
>> imrpove the performance for around 15%. I'm pretty sure we can avoid
>> looking into the index, as soon as we already have a cache of the
>> existing aliases. The pb is that it's just a cache, and if the alias is
>> not in the cache, we have to fetch the alias index. This become a pb
>> when we have a lot of aliases, something unlikely to happen.
>>
>> how about setting a limit on the number of aliases that will be held in
> the cache
> and we store all the aliases in this cache, if the alias cache has less
> than this limit we
> don't need to look into the index (i.e we will always have all the aliases
> in memory)
> (here the assumption is that most server installations will have less
> aliases than
> the given threshold)

Yes, this is probably the best solution. We just have to keep a counter
of aliases beside the alias cache.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com