From dev-return-25285-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Thu May 29 05:21:37 2008
Return-Path:
Delivered-To: apmail-directory-dev-archive@www.apache.org
Received: (qmail 13379 invoked from network); 29 May 2008 05:21:37 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 29 May 2008 05:21:37 -0000
Received: (qmail 17898 invoked by uid 500); 29 May 2008 05:21:38 -0000
Delivered-To: apmail-directory-dev-archive@directory.apache.org
Received: (qmail 17843 invoked by uid 500); 29 May 2008 05:21:38 -0000
Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: "Apache Directory Developers List"
Delivered-To: mailing list dev@directory.apache.org
Received: (qmail 17832 invoked by uid 99); 29 May 2008 05:21:38 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 May 2008 22:21:38 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 209.85.198.228 as permitted sender)
Received: from [209.85.198.228] (HELO rv-out-0506.google.com) (209.85.198.228)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 May 2008 05:20:51 +0000
Received: by rv-out-0506.google.com with SMTP id g37so3933037rvb.25
for ; Wed, 28 May 2008 22:21:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
bh=xsjuK22b8NdhLTDOyvHvhiANO46d3wo2yfl2MABwc0I=;
b=ps3PbmIFzVpYVrQIJ8Gytzxw9r+hrWEpFg295YzpL5sHvrfrt3ASiRVFvSSbC3d8zN1Qta2PxYNCpF2eenMVTOeoRdAyd/XyO/XXus3wsAQiKgCJL5+cT0jkrMKriBH0SmpNMR2gJzLpRAy+bjyHJU8G20xypB/IyGyt0++5IjQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
b=cO23pGkqafMKsoNKNUcXc8xapL0VLJJWtYIWPIibF9ptwUhZiGGKRsg2Yj1oe1KztQ8Ks04U4RW23x/ooyTuribnCtsL/vysxsNnZeydz8vj2yQaNVY9bRvAj5dt/PRQ/THbsUJR3CdS1Hm+MA+I8dxxhoHe5v8N9C2nFyRzneo=
Received: by 10.141.204.16 with SMTP id g16mr1785203rvq.275.1212038467561;
Wed, 28 May 2008 22:21:07 -0700 (PDT)
Received: by 10.141.113.13 with HTTP; Wed, 28 May 2008 22:21:07 -0700 (PDT)
Message-ID:
Date: Thu, 29 May 2008 01:21:07 -0400
From: "Alex Karasulu"
Sender: akarasulu@gmail.com
To: "Apache Directory Developers List" ,
elecharny@apache.org
Subject: Re: [perf] Should we really deep clone the serverEntry ?
In-Reply-To: <483E0B9A.7070009@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_19827_6483400.1212038467547"
References: <483E0B9A.7070009@apache.org>
X-Google-Sender-Auth: 208c5794027a4251
X-Virus-Checked: Checked by ClamAV on apache.org
------=_Part_19827_6483400.1212038467547
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Wed, May 28, 2008 at 9:49 PM, Emmanuel Lecharny
wrote:
> Hi,
>
> I just realize that it might not be a good idea to deep clone ServerEntry
> instances when searching data into the server.
>
> Currently, when we get an entry from the backend, we clone it in order to
> avoid modification of the cache (the entry might be - and hopefully is -
> cached) when removing attributes from it before returning it to the user
> (for instance when removing operational attributes, or selecting the
> attributes the user have asked for).
>
> But we never remove a value, or modify an attribute, unless another request
> modify the entry. So my question : what if we simply clone the ServerEntry,
> but not the attributes ? It will save a huge amount of processing (cloning
> attributes costs around 28% of the global time spent into the server).
>
> What if we add a lock mechanism (a monitor for instance) to protect entries
> in the cache from being modified while they are searched ? It could be as
> simple as a flag which will be set when the entry has been modified (a
> antomicBoolean could be just enough).
>
> Did I missed something ? Does it make sense ?
>
Hmmm search I think uses lookup for entries that are not pulled out of the
master table. Basically searches are conducted on system indices (user
indices too if present). The lower layers return IndexEntry objects which
contain index tuples. If the object is to be returned or pulled to
calculate some assertion then it is set via IndexEntry.setObject().
Write operations also use lookup() operations. So I think it might have
been a bad idea to use this ClonedServerEntry object perhaps.
Let me think about this one some more. I need to look at it in depth a
little more.
Thanks,
Alex
------=_Part_19827_6483400.1212038467547
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Wed, May 28, 2008 at 9:49 PM, Emmanuel Lecharny <elecharny@apache.org> wrote:

Hi,

I just realize that it might not be a good idea to deep clone ServerEntry instances when searching data into the server.

Currently, when we get an entry from the backend, we clone it in order to avoid modification of the cache (the entry might be - and hopefully is - cached) when removing attributes from it before returning it to the user (for instance when removing operational attributes, or selecting the attributes the user have asked for).

But we never remove a value, or modify an attribute, unless another request modify the entry. So my question : what if we simply clone the ServerEntry, but not the attributes ? It will save a huge amount of processing (cloning attributes costs around 28% of the global time spent into the server).

What if we add a lock mechanism (a monitor for instance) to protect entries in the cache from being modified while they are searched ? It could be as simple as a flag which will be set when the entry has been modified (a antomicBoolean could be just enough).

Did I missed something ? Does it make sense ?

Hmmm search I think uses lookup for entries that are not pulled out of the master table. Basically searches are conducted on system indices (user indices too if present). The lower layers return IndexEntry objects which contain index tuples. If the object is to be returned or pulled to calculate some assertion then it is set via IndexEntry.setObject().

Write operations also use lookup() operations. So I think it might have been a bad idea to use this ClonedServerEntry object perhaps.

Let me think about this one some more. I need to look at it in depth a little more.