You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Jörg Maaß <jo...@eacg.de> on 2013/12/06 15:47:39 UTC
Sizing and configuration of ApacheDS for production
Dear all,
here’s 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=bla,ou=blub,ou=whatever)
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 index 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 sort out the objects it needs.
The JVMs for ApacheDS have 2 GB memory each.
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üßen
Jörg Maaß
--
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ße 2-4, 60306 Frankfurt am Main
Handelsregister Frankfurt am Main HRB 84852
Geschäftsführer: Jan Thielscher
Re: Sizing and configuration of ApacheDS for production
Posted by Kiran Ayyagari <ka...@apache.org>.
On Fri, Dec 6, 2013 at 8:17 PM, Jörg Maaß <jo...@eacg.de> wrote:
> Dear all,
>
> here’s 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=bla,ou=blub,ou=whatever)
> 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 index
> 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 sort
> 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üßen
>
>
>
> Jörg Maaß
> --
> 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ße 2-4, 60306 Frankfurt am Main
> Handelsregister Frankfurt am Main HRB 84852
> Geschäftsführer: Jan Thielscher
>
>
--
Kiran Ayyagari
http://keydap.com
Re: Sizing and configuration of ApacheDS for production
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 12/06/2013 03:47 PM, Jörg Maaß wrote:
> All relevant attributes that are being looked up are indexed with an index size of 10000 each.
and
> The search strategy is somewhat awkward: the application looks up an Orgunit and retrieves all child objects, then applies an AND filter to sort out the objects it needs.
Do I understand correctly the application fetches all entries of an OU
including all attributes without using a reasonable search filter?
If that is the case my first advice is to modify the application,
transfering huge amount of data over the wire is a performance killer.
If that is really not possible then I think the indexes don't make sense
because they are not used anyway, instead increase the entry cache. Also
think about caching the data on the client side.
Kind Regards,
Stefan