topic Re: AccessDecisionVoter - performance/scalability concerns in Alfresco Archive https://connect.hyland.com/t5/alfresco-archive/accessdecisionvoter-performance-scalability-concerns/m-p/35095#M18418 <HTML><HEAD></HEAD><BODY><SPAN>Well spotted <img id="smileyhappy" class="emoticon emoticon-smileyhappy" src="https://connect.hyland.com/i/smilies/16x16_smiley-happy.png" alt="Smiley Happy" title="Smiley Happy" /> 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.</SPAN><BR /><BR /><SPAN>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.</SPAN><BR /><BR /><SPAN>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.</SPAN><BR /><BR /><SPAN>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.</SPAN><BR /><BR /><SPAN>Thanks,</SPAN><BR /><BR /><SPAN>Kevin</SPAN></BODY></HTML> Fri, 10 Feb 2006 11:27:08 GMT kevinr 2006-02-10T11:27:08Z AccessDecisionVoter - performance/scalability concerns https://connect.hyland.com/t5/alfresco-archive/accessdecisionvoter-performance-scalability-concerns/m-p/35094#M18417 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 j Thu, 09 Feb 2006 16:59:51 GMT https://connect.hyland.com/t5/alfresco-archive/accessdecisionvoter-performance-scalability-concerns/m-p/35094#M18417 bradw 2006-02-09T16:59:51Z Re: AccessDecisionVoter - performance/scalability concerns https://connect.hyland.com/t5/alfresco-archive/accessdecisionvoter-performance-scalability-concerns/m-p/35095#M18418 <HTML><HEAD></HEAD><BODY><SPAN>Well spotted <img id="smileyhappy" class="emoticon emoticon-smileyhappy" src="https://connect.hyland.com/i/smilies/16x16_smiley-happy.png" alt="Smiley Happy" title="Smiley Happy" /> 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.</SPAN><BR /><BR /><SPAN>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.</SPAN><BR /><BR /><SPAN>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.</SPAN><BR /><BR /><SPAN>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.</SPAN><BR /><BR /><SPAN>Thanks,</SPAN><BR /><BR /><SPAN>Kevin</SPAN></BODY></HTML> Fri, 10 Feb 2006 11:27:08 GMT https://connect.hyland.com/t5/alfresco-archive/accessdecisionvoter-performance-scalability-concerns/m-p/35095#M18418 kevinr 2006-02-10T11:27:08Z