[OTDev] OpenAM performance

Vedrin Jeliazkov vedrin.jeliazkov at gmail.com
Tue Jul 5 20:55:04 CEST 2011


Hi,

On 5 July 2011 20:02, Nina Jeliazkova <jeliazkova.nina at gmail.com> wrote:

> P.S. IMHO the memory requirements of OpenDS are rather ridiculous.

Well, a more precise statement would be that "the memory requirements
of OpenDJ running with default settings when queried by OpenAM and
having to deal with thousands of policies are rather ridiculous". I'm
still experimenting with tweaking the external OpenDJ settings in an
attempt to optimise its performance for our specific needs. In case
that these experiments don't improve dramatically OpenDJ's
performance, our next option would be to study what kind of queries
OpenAM is submitting to OpenDJ and eventually try optimising those as
well.

A hint for those willing to have a look at OpenAM's source code is
that it uses a lot the following entry: sunxmlKeyValue

>  After
> all, these 40K policies fit in about 50MB of memory , if one consider them
> as strings, and my calculations are not completely wrong.  Perhaps we are
> still unaware of some configuration magic in OpenAM/ OpenDJ (LDAP)backend.

This is definitely something we should look into. However, please
don't forget that OpenAM's internal LDAP store (used on the production
server) is supposed to run as a black box (this is essentially a
stripped-down version of OpenDS, not to be configured by end users).

>  The OpenDJ uses Berkeley DB as a backend, and a (distributed) version of
> BDB  is reported to handle all Google accounts and associated properties ...

That's interesting. Is it the Berkeley DB Java Edition or something
else? OpenDJ has a parameter passing mechanism allowing to tweak
Berkeley DB settings as well, but that would require additional
reading. In fact I don't know whether the memory requirements that we
have identified so far are due to OpenDJ in general or are specific to
the Berkeley DB Java Edition that it uses as a backend for storing the
policies.

V.



More information about the Development mailing list