Le 23/02/16 19:36, Jan Sindberg a écrit : >> 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 ?
We have had a discussion about adding a cache in Fortress last october in Budapest. Bottom line, what would be the best solution would be to have ApacheDS embedded into Fortress, with a in-memory backend (which we have in ApacheDS) and use it as a cache. If the element we are looking for is not present, then we fetch it from the remote server. Another option would be for the embedded ApacheDS server to be a consumer of the remote LDAP server : it will not allow any update to be done locally, but will be informed immediately when such a change is done on the remote server. We agreed that there is a bit of work to get this done, but all in all, it's feasible. We probably have to strip down some of the code in ApacheDS (like we don't need the JDBM part, nor the Kerberos/DHCP/DNS code), making it a bit lighter. My 2 cts.
