> Fra: Shawn McKinney [mailto:[email protected]] > Sendt: 23. februar 2016 14:27 > > > On Feb 23, 2016, at 6:19 AM, Jan Sindberg <[email protected]> wrote: > > > > The first local ApacheDS was set up according to the ten minutes guide and > the reload-script. The next ones were setup by importing ldif-files. They are > also set up with SSL. > > We are currently seeing the time when calling sessionPermissions in the > area of 400ms. For a local ApacheDS we see around 7ms or less. The ping- > time to the server is approx. 25 ms (non ssl), and I can't imagine that SSL > should add overhead around 350ms when first the connection is created. > > My question is if I have missed something around indexes specific to > Fortress RBAC? > > Doubtful there is an index issue here. I also doubt that it is SSL related, > assuming the connections are pooled in the normal way fortress does it. > > It is best to establish a baseline for the performance of this function. > There is > a jmeter benchmark procedure to test sessionPermissions. I suggest you use > that to determine what your performance is under various conditions. > > There is some info on how to use the tests in the README. > > Shawn
It turns out that we are using AWS Instance type: t2.micro which provides a baseline capability performance equivalent to 20% of a CPU core. We have added a cache with timeout for session-permissions. With this in mind and our earlier talk (in another thread) about network latency, I suggest that we consider adding such caching to Fortress core. 1) Caching of permissions - pr user? 2) Add config option for the cache manager (as done for other managers) 3) Consider making it easy to add event integration between Fortress Commander and any application using Fortress Core, such that changes made via Commander will notify the cache and invalidate as appropriate. - Are there any smart ways to get such events directly from OpenLDAP or ApacheDS such that we can make it complete and totally easy to use ? // Jan
