directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Performances : some other potential improvements
Date Thu, 01 Aug 2013 22:48:50 GMT
Le 8/1/13 9:21 PM, Kiran Ayyagari a écrit :
> On Thu, Aug 1, 2013 at 11:47 PM, Emmanuel Lécharny <elecharny@gmail.com>wrote:
>
>> How can we improve this ?
>> -------------------------
>>
>> o The first step is tryng to retrieve the entryUUID associated with the
>> baseDN. It's likely to be done many times, so we could benefit from
>> using a <Dn, entryUUID> cache, to avoid those costly operations (keep in
>> mind that we not only do comparisons, we also potentially fetch pages
>> from the disk if they are not present in memory). A MRU cache will save
>> us a lot of time here.

>> we have a DN cache (DnFactory) but we are not using it effectively

This is a bit different, but we could change it to store the entry's
UUID and leverage it. Sounds like a good idea.
>
> Now, it's a bit hard to get rid of this computation : the comparator is
> associated with the AttributeType, and we  don't have one which does not
> normalize the value for the server, and another one that normalize the
> values for the client (keep in mind that the SchemaManager is used on
> the client and the server). So how do we distinguish the use case we are
> in ? Tht's the key ; if we are in the server, we should not normalize,
> and if we are on the client, we must normalize...
>
> Atm, I have no idea on how to do that. The only thing is that it's
> extremely critical to avoid this extra computation.
>
> thinking about it  realized that a flag based check to avoid normalization
> is
> dangerous and will break an embedded server (where the user uses
> CoreSession API)

Well, the normalization occurs after the coreSession, so we should be safe.


>
> How can we improve this ?
> -------------------------
>
> It's not simple. One can think that an equality filter wil return only a
> few values, or even 1 or 0. this is true for the kind of filter I'm
> using n this test, but it's not true for a filter like
> (ObjectClass=person), which can select thousands of candidates.
>
> One possible way would be to get rid of the count() method, and to fetch
> the candidate immediately instead, up to a number of candidate (100 ?).
> The fetched candidate will be stored associated with the annotated node,
> and can be used immediately by the build() method, instead of being
> feteched a second time.
>
> count() method in Mavibot is efficient and accurate (cause it stores the
> number
> of elements present in the tree), so I would still lean towards using count

This is true if you are considering the counter at the top level of a
tree. But the question is not really about using this counter or not,
but how to spare the double check for the candidates.

As soon as we can grab the count of candidates, it's almost free to get
the candidate and to store them somwhere withong the ExprNode, to reuse
them in the build() method, without having to go down the tree again
down to the key.

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


Mime
View raw message