Performance while working on asset workflow process with multiple users/group

[Sumanth-Narra]

Hi All

I’ve a doubt related to multiple users logged in into author instance at a time and working concurrently!

We have 200+ users/groups on an instance and users will be working on updating assets, changing the metadata depends on the request so and so....

As i know N number of users/groups won't effect a instance reference: How many users we can create in AEM?

Nowhere in official documentation I could find that states any performance impact or any limitation on working with multiple users simultaneously. But, could you please tell me if there can be performance issues while working with so many users simultaneously.

Also, provide any documentation links which states anything related to it.

And, if there’re impacts then what all scenarios to be considered to make it work in a better way?

Thanks,

[berliant]

You can consider configuring an AEM DAM Offloading Offloading Jobs.

Such a configuration helps to relax main AEM server and run DAM Update Asset workflow on a worker AEM

[Vish_dhaliwal]

If the number of concurrent users working on the author is more than hundreds then there is a Mongo MK deployment option that you can think of.

Of course, there are other factors as well. Please review this article : https://docs.adobe.com/content/help/en/experience-manager-64/deploying/deploying/recommended-deploys...

Performance testing: https://helpx.adobe.com/ca/experience-manager/6-4/sites/deploying/using/best-practices-for-performan...

[Jaideep_Brar]

Sumanth,

I believe you need to scroll a bit down on google results and you will find the doc at [1] which provides details on when to start using MongoDB based on the number of user and other activities. More details at [1]

When to use MongoDB with AEM

MongoDB will typically be used for supporting AEM author deployments where one of the following criteria is met:

• More than 1000 unique users per day;
• More than 100 concurrent users;
• High volumes of page edits;
• Large rollouts or activations.

If your setup has the above requirements, you need to use MongoDB otherwise use tarmk. Please let me know what kind of documentation you are looking for? Creating docs based on each customer's setup does not seem to be a sustainable way of documenting.

[1] AEM with MongoDB

[sunjot16]

In addition to recommendations suggested by berliant, Vish.dhaliwal & JaideepBrar, when there are a lot of users dealing with Asset workflows, there maybe huge ingestion loads too.

To optimize high ingestion loads you can define a workflow as transient.

The following document may be helpful in explaining the best practices when dealing with Asset Workflows:

1.) https://docs.adobe.com/content/help/en/experience-manager-64/developing/extending-aem/extending-work...

2.) Assets Performance Tuning Guide

[Jörg_Hoh · Accepted solution]

First of all, the load users create on a system is always depending on the type of work they do. 2 users constantly uploading assets can create more load than 100 users just typing text into pages.

Your case of working with assets is likely an intense one, so the number of users working concurrently is definitive a very important factor. 200 concurrent users working with assets ... I would not wonder in the first place that you have some bad experience regarding the performance of the UI.

In that case there are multiple paths to go:

* First of all, the newer the AEM version, the more optimizations are builtin to handle such scenarios more gracefully. 6.2 to 6.3 was a huge improvement, and also 6.3 to 6.4 gives you benefits. What AEM version are you using?

* The next step is that you need to find the bottleneck regarding performance. There are many ways to approach it, I would recommend system monitoring (mostly CPU and I/O) and also analyzing threaddumps.

CPU monitoring indicates if you should add more CPUs (or more powerful CPUs), while the threaddump analysis gives you insight where the CPU is actually spent. In many Asset instances CPU is really a limiting factor (unlike sites), so you should pay special attention to it.

But it's also good to understand where these CPU cycles are spent; it can give you hints where you should start to optimize.

HTH,

Jörg