AccessDecisionVoter - performance/scalability concerns

[bradw]

I have a question regarding the AccessDecisionVoter implementation. Specifically, how do you forsee this scaling in a heavily-used site with large data sets? It would seem to me that you'll take an incredible hit trying to individually query each node for permission (as opposed to using a database join, for example).

Is there some other paradigm that is better suited for larger datasets and higher load? I can see how caching will help improve performance, but you still take the initial hit, and you have a trade-off of not being able to rely on up-to-the-date security information for deciding on access.

Any thoughts?

Thanks,
Brad

[kevinr]

Well spotted That code path was identified as a performance issue in 1.1.2 - we've added a permssions cache which make a big difference to the overall speed and responsiveness of the repository for 1.2.

You are correct in that dealing with "node" objects in memory all the time is a serious performance consideration - we have tried our best to add appropriate caching to make this as fast as possible.

A content repository with powerful functionality such as advanced permissions, rules and other node based features is unlikely to ever be as fast as a pure database join scenario.

So, for specific high-load scenarios and huge scale datasets, we have been discussing the possibilities of alternative schemas. All the services in Alfresco are interface based and pluggable using Spring. This means that if a different schema was envisaged for a specific use-case of the repository then the appropriate services can be replaced to work with this schema. In the future I would imagine that specific applications of Alfresco could take advantage of this kind of architecture.

Thanks,

Kevin