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 ayyagarikiran@gmail.com
 designates 209.85.212.174 as permitted sender)
MIME-Version: 1.0
Sender: ayyagarikiran@gmail.com
In-Reply-To: <C52E9DE0-6182-4789-B11E-9435FA36C271@eacg.de>
References: <C52E9DE0-6182-4789-B11E-9435FA36C271@eacg.de>
Date: Fri, 6 Dec 2013 20:28:59 +0530
Message-ID: 
 <CABzFU-fiBNXJoDnju-4at=B7HvBhAC5L9bFKQjKQ0m1vdzBZpw@mail.gmail.com>
Subject: Re: Sizing and configuration of ApacheDS for production
From: Kiran Ayyagari <kayyagari@apache.org>
To: users@directory.apache.org
Content-Type: multipart/alternative; boundary=001a11c3473ad1e48004ecdee229

--001a11c3473ad1e48004ecdee229
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 6, 2013 at 8:17 PM, J=F6rg Maa=DF <joerg.maass@eacg.de> wrote:

> Dear all,
>
> here=92s a couple of questions or you savvy guys:
>
> We plan to use two ApacheDS servers in a multi master replication
> configuration with load balancers in front for a production setup.
> At present, we have about 30.000 entries in a domain in three trees. The
> trees are pretty flat, with a maximum depth of three layers (e.g.
> ou=3Dbla,ou=3Dblub,ou=3Dwhatever)
> The frontend server have a connection pool of 400 connections towards the
> LDAP servers each.
> All relevant attributes that are being looked up are indexed with an inde=
x
> size of 10000 each.
> The current number of nbthreads per server are 150.
> The search strategy is somewhat awkward: the application looks up an
> Orgunit and retrieves all child objects, then applies an AND filter to so=
rt
> out the objects it needs.
>
like you said, it _is_, well may be that is based on the need however this
is likely to give the end users
a 'slow' feeling due to the filtering and re-search by the client(web
application?) even when server
performs each search better (w.r.t response time).

> The JVMs for ApacheDS have 2 GB memory each.
>
I would strongly suggest you to use the latest trunk(nothing to be scared
of, IMO it is stable enough,
and you can give a try in your test env) to utilize the recent changes done
in cache management
and this will definitely help in boosting the search performance in this
environment that is equipped
with good resources.

Please let us know if you run into any problems.


> Can you give us some hints as to optimize the performance of this setup?
>
> Thanks a lot in advance!
>
>
> What we see with the he
> Mit freundlichen Gr=FC=DFen
>
>
>
> J=F6rg Maa=DF
> --
> T: +49 6027 409219
> M: +49 178 5352364
> F: +49 6027 409220
> W: http://www.eacg.de
> ----
> EACG GmbH
> Enterprise Architecture Consulting Group
> OpernTurm 16.OG, Bockenheimer Landstra=DFe 2-4, 60306 Frankfurt am Main
> Handelsregister Frankfurt am Main HRB 84852
> Gesch=E4ftsf=FChrer: Jan Thielscher
>
>


--=20
Kiran Ayyagari
http://keydap.com

--001a11c3473ad1e48004ecdee229--