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 (asf.osuosl.org: local policy)
Date: Mon, 05 Jun 2006 00:03:31 -0700
From: Quanah Gibson-Mount <quanah@stanford.edu>
To: Apache Directory Developers List <dev@directory.apache.org>
cc: elecharny@iktek.com
Subject: Re: Various questions
Message-ID: <70EF1ECB44814A84D5CDA363@SW-90-717-287-3.stanford.edu>
In-Reply-To: <4483D3F0.8040206@gmail.com>
References: <CCB3F244C8D468D73FACD489@SW-90-717-287-3.stanford.edu>
 <4483D3F0.8040206@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


--On Monday, June 05, 2006 8:49 AM +0200 Emmanuel Lecharny=20
<elecharny@gmail.com> wrote:

> Quanah Gibson-Mount a =C3=A9crit :
> Hi !
>
>> Hi,
>>
>> I'm looking at apache DS as compared to OpenLDAP, and have an initial
>> set of questions:
>>
>> (a) is it possible to bulk load an LDIF file while the server is
>> offline? If yes, how?
>
> Well, no.
>
>> (b) If I choose to load an LDIF file via the server.xml file, is the
>> beginning and end of the load logged, so that a timing mark can be
>> drawn from it?
>
> It's better to do it another way. If you wait untl 1.0-RC4, which will be
> out around this week or next week, you will be able to use an
> apacheds-tools to import LDIF files into ADS. FYI, we have done some load
> tests lately, and what I can say is that loading 10 000 entries into
> OpenLdap takes 9 mins, and 1min 40sec on ADS.

I'm curious on how you are setting up OpenLDAP, because I can load a=20
400,000 entry LDIF with heavy (90+ attributes) indexing in 14 minutes and=20
30 seconds.  My guess is you don't understand how to configure OpenLDAP.

I tried loading a 250,000 (very small) database into Apache DS tonight, and =

it died horribly somewhere between 10k and 11k entries.

ldapadd logged the following error:

adding new entry uid=3Duser.11084,ou=3DPeople,dc=3Dexample,dc=3Dcom
ldap_add: Loop detected
ldap_add: additional info: failed to add entry=20
uid=3Duser.11084,ou=3DPeople,dc=3Dexample,dc=3Dcom


>> (c) How does one tune the underlying database?
>
> No way to do it right now.
>
>> (d) Is there any way to tune an entry cache, etc, for Apache DS?
>
> It's a improvment listed in JIRA : currently, the cache size is fixed
> (bad!), and we want to change that
>
>> (e) When one specifies an index for an attribute, I see no way to
>> differentiate between equality, substring, presence, etc.  If an
>> attribute is indexed, is it then simply indexed for all possible
>> search methods?
>
> Hmmm, I have to check. I think it's equality. Presence is not implemented
> atm, AFAIK


What about substring?


>> (f) Are there any other general guidelines for tuning Apache DS?
>
> Not too much. We are not currently working too much on adding tunning
> tools on the server, because we are working hard to fix some
> functionnalites issues, and also some real serious performance problems
> that kill the server when you have more than, say, 100 entries ;(
>
> What I may suggest is that you fill JIRA's issues for those point you
> think are lacking in ADS, in order for us to be able to fix those points
> and not forget them (for instance, your index question is important). We
> would be very pleased to ear about any bug, any missing functionnality,
> any performance comparison you can do, this will help us to build a
> better server. And if you have time, well, we also need some help
> improving it, it's doco, it's testcases, and so on :)


I'll note that in my performance test with OpenLDAP, I can achieve nearly=20
14,000 authentications/second.  There are two searches per authentication,=20
so nearly 28,000 search/second.  The highest number I've seen quoted on=20
this list is 780 or so searches/second.  Is there anyone with better=20
results?

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html