Hi all
I've come across an issue that as far as I can see may seriously affect performance of any sizeable system with lots of sites where records management is installed - and a potential easy workaround
We've recently been trying to track down some performance issues we've been seeing in our live instance where different users were getting (consistently) different times from other users when navigating through the same folders. For some users it was nice and quick and was about 4 seconds for a particular folder but for others it was taking upwards of 30-40 seconds for the same folder. It was consistent, so for a particular user it would always be in the region of 30-40 seconds and for the other it would always be 3-4. The folder we looked at for tracing had just over 50 documents, so not very large either.
We checked the usual things, like general system performance, whether one node was behaving more slowly than the other etc. but after tracing the performance bottlenecks we were able to find that the performance was all being taken up in the Share call to share/service/components/documentlibrary/data/doclist/all/site/<sitename>/documentlibrary/<path>. What was strange was that the corresponding call to the repository finished and returned in under a second. So where was the time going?
What I found when looking at this was that as well as making the single call to get the data from Alfresco, share was going off to Alfresco another 100 times or so (for this folder with 51 items) and calling /api/sites again and again and again.
I tracked this back to a badly written evaluator (DocLibRmSiteExistsEvaluator.java) from the RM module that makes a call to alfresco for every document that it is used to evaluate. This would potentially be alright if it was needed, but the evaluator is only intended to determine if the records management site exists?
It's used in the createRecord action so virtually every document that a user has the ability will be write to will subjected to this unless it's locked, synced or a rejected record (this also by the way was the reason for the difference in performance between users - users with fewer rights weren't encountering this evaluator as the check for whether they could edit the document came first
).
Surely there is a better way of doing this? There's no attempt to cache the results so it's literally blindly asking the same question again and again, and performance will continue to degrade as the system gets larger, not just as the number of documents in the folder grows, but also as the number of sites in the system grows. It's also a really strange approach to take - given the nature of records management, it's not likely that the existence of the RM site will be subject to so much change that it needs to be rechecked for each document?
In order to get a quick resolution we have applied a small change, but one that drastically increases performance. We know that we have a records management site and that we will for the foreseeable future (again given the nature of records management ). Because of this we have overridden the evaluator bean, "evaluator.rm.doclib.rmSiteExists", with one that simply returns true. When we get some more time, we'll likely look to put in a cleaner change, removing or modifying where this evaluator is used instead.
I've raised this as an issue with support, but just in case this information is useful to anyone else in the meantime as it is an easy change for a large reward
Regards
Steven
I've come across an issue that as far as I can see may seriously affect performance of any sizeable system with lots of sites where records management is installed - and a potential easy workaround
We've recently been trying to track down some performance issues we've been seeing in our live instance where different users were getting (consistently) different times from other users when navigating through the same folders. For some users it was nice and quick and was about 4 seconds for a particular folder but for others it was taking upwards of 30-40 seconds for the same folder. It was consistent, so for a particular user it would always be in the region of 30-40 seconds and for the other it would always be 3-4. The folder we looked at for tracing had just over 50 documents, so not very large either.
We checked the usual things, like general system performance, whether one node was behaving more slowly than the other etc. but after tracing the performance bottlenecks we were able to find that the performance was all being taken up in the Share call to share/service/components/documentlibrary/data/doclist/all/site/<sitename>/documentlibrary/<path>. What was strange was that the corresponding call to the repository finished and returned in under a second. So where was the time going?
What I found when looking at this was that as well as making the single call to get the data from Alfresco, share was going off to Alfresco another 100 times or so (for this folder with 51 items) and calling /api/sites again and again and again.
I tracked this back to a badly written evaluator (DocLibRmSiteExistsEvaluator.java) from the RM module that makes a call to alfresco for every document that it is used to evaluate. This would potentially be alright if it was needed, but the evaluator is only intended to determine if the records management site exists?
It's used in the createRecord action so virtually every document that a user has the ability will be write to will subjected to this unless it's locked, synced or a rejected record (this also by the way was the reason for the difference in performance between users - users with fewer rights weren't encountering this evaluator as the check for whether they could edit the document came first
). Surely there is a better way of doing this? There's no attempt to cache the results so it's literally blindly asking the same question again and again, and performance will continue to degrade as the system gets larger, not just as the number of documents in the folder grows, but also as the number of sites in the system grows. It's also a really strange approach to take - given the nature of records management, it's not likely that the existence of the RM site will be subject to so much change that it needs to be rechecked for each document?
In order to get a quick resolution we have applied a small change, but one that drastically increases performance. We know that we have a records management site and that we will for the foreseeable future (again given the nature of records management
). Because of this we have overridden the evaluator bean, "evaluator.rm.doclib.rmSiteExists", with one that simply returns true. When we get some more time, we'll likely look to put in a cleaner change, removing or modifying where this evaluator is used instead.I've raised this as an issue with support, but just in case this information is useful to anyone else in the meantime as it is an easy change for a large reward
Regards
Steven
