[OTDev] OpenAM performance
Andreas Maunz andreas at maunz.deMon Jul 4 11:52:24 CEST 2011
- Previous message: [OTDev] OpenAM performance
- Next message: [OTDev] OpenAM performance
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message: [OTDev] OpenAM performance
- Next message: [OTDev] OpenAM performance
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Development mailing list