[OTDev] OpenAM performance

Andreas Maunz andreas at maunz.de
Mon Jul 4 11:52:24 CEST 2011


Hi Vedrin,

I have been using the OpenAM-integrated LDAP policy store (only users
are in the Website-LDAP).
I had also the policy store in mind when pondering about the reasons
for deletion being so slow. 
There seems to be a faster LDAP implementation delivered with OpenAM
9.5.x but of course LDAP is still optimized for reading. 

I agree we would probably have to drop existing policies when moving to
a newer version of OpenAM. Given your below results, the most important
step besides upgrading will be a real powerful LDAP service for
configuration store.

Best regards
Andreas

On Mon, 4 Jul 2011 12:15:31 +0300, Vedrin Jeliazkov
<vedrin.jeliazkov at gmail.com> wrote:
> Hi again,
> 
> On 4 July 2011 10:23, Vedrin Jeliazkov <vedrin.jeliazkov at gmail.com> wrote:
> 
>> Some findings of general interest:
>>
>> 1) The CPU usage proportion between OpenDJ, MySQL, and OpenAM+Policy
>> is roughly 10:2:1. This highlights the need to have a dedicated
>> powerful server (even better -- a pool of cooperating servers) for
>> LDAP or eventually use a different backend (e.g. general purpose
>> RDBMS) that scales better for workloads that are not predominantly
>> read-only.
> 
> A closer investigation reveals that at the moments when the policy
> removal tasks are run (periodically), the above mentioned CPU usage
> proportion changes rather dramatically to 20:2:1. I've also forgot to
> mention that OpenAM+Policy share the same Tomcat instance with Ambit2
> :-)
> 
> V.
> 
> PS: A possible temporary workaround for this performance issue could
> consist in adding invalidating rules in the policies that we want to
> remove, while postponing the actual  (batch) policy removal to a more
> convenient time (e.g. when the service load is below a certain
> threshold). We have to see though whether the addition of such rules
> would be a less CPU- and memory-bound task.
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development

-- 
http://www.maunz.de

      Not always does the squeaky wheel get the grease- sometimes it
gets replaced.



More information about the Development mailing list