> On Jan 6, 2016, at 8:56 AM, Jan Sindberg <[email protected]> wrote: > > n our setup we have lists (or report) with many data items. Some of the > attributes on these items are guarded by permissions that restrict viewing - > an icon for restricted information is shown instead. This is typically > handled in one thread. In production we will end up with a setup where the > ping time between the server and the LDAP is typically 16 ms. Ignoring > processing on the LDAP that means that at most 30 requests pr. thread can be > processed pr. second. With 2000 permission checks on a list it will take more > than a minute for permission checks alone. > > The quick and simple solution is to add a temporary map for caching responses > pr. session / page view. We already have some helper classes around the > fortress api and the session handling, so it is not such a big issue to do > that. It is more of a surprise because I was focused on the 8K/sec and forgot > that it includes multiple threads and probably is run locally with a minimum > of network latency. > > Did I miss a build in mechanism for handling this issue or is there any plans > on adding more aggressive caching of permission checks?
No caching of perms in fortress currently. Worth thinking about adding a permission cache. I don’t think that would be difficult to do. I suppose I never went there because that operation is typically so fast it wasn’t worth the trouble. I can see how it would be useful in a high latency environment. There is one thing you can do now, call the accessmgr.sessionpermissions api, and store that result set in a map locally. That is a typical use case for web apps where each page loading requires multiple permission checks. Shawn
