Folder.getFolderTree(-1) taking lot of time

[jgupta]

Hi Guys,

We are trying to build a folder tree in our custom web application from alfresco. I am using Folder.getFolderTree(-1) to get entire folder tree in one go. We have folder levels upto 5 with around 5000 folders.

I notice that alfresco is taking almost 70 seconds to the response. Is there any specific tuning I can do to optimize this. We cannot do pagination here since business wants to report all the available folders on the web UI.


Regards
Jiten

[afaust]

Hello,

first of all: If business wants to have thousands of objects loaded in one operation, then they should be prepared to wait a while.
second of all: Business requirements are usually not an excuse not to use pagination - typically, you can fulfill those requirements even with incremental loading / rendering and have a much better user experience.

Have you done some more investigation to find out if Alfresco is taking most of that time or the database? What is the configuration of your CMIS operation context? You should have it set to only retrieve the properties / information you really require, so potentially exclude renditions, relations, allowable actions - if you don't need them.

Regards
Axel

[jgupta]

Thanks for the answer.
Yes we are working on pagination in parallel. We tried setting operational context just to retrieve path and excluding relation, acls, relationship etc. But response time is same with and without operational context. We have CPU going to 70-80 % with just 3 concurrent users.

I wanted to know if this kind of response time is normal with alfresco when retrieving huge folder tree(around 5000) using CMIS api with M1 medium machine and allocating 2GB ram to tomcat ? Is there any benchmarking for cmis api with alfresco ?

Regards
Jiten

[afaust]

Hello,

well, I would consider this response time as "not normal" for a "sufficiently dimensioned" Alfresco installation. But reading that you only allocated 2 GiB RAM to Alfresco Tomcat, I am very hesitant to apply "sufficiently dimensioned" to your environment. While 2 GiB can be enough for evaluation purposes and simple, low usage scenarios, it can quickly be exhausted when loading large volumes of data (and doing that in parallel). Furthermore, the 2 GiB is only the total and is separate into various memory areas at runtime. If some of those areas run full during runtime, you can run into issues such as "GC thrashing" which means the application is mostly dealing with cleaning up memory to use, filling what little it could clean up immediately and starting over… This causes high CPU usage and massive increase of response times (GC involves "stop-the-world" pauses to the entire application).

Such a phenomenon can typically be diagnosed when looking at the runtime with a JMX client. Try allocating 1 - 2 GiB additional RAM and see what happens - if response times radically improve, you did suffer from "GC thrashing".

Regards
Axel