Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

5000 Pages Under Single Node - Performance Impact?

Avatar

Level 3

Hi, We are migrating content from legacy system where content is stored in flat structure. Each page has unique name and there is no identifier or pattern. 

Example: /site/test/page...1    -> /site/test/page...5000

Approximately there are 5000 pages. After we move to AEM this old links should still work. Is there a performance impact on creating 5000 pages under single node. I am aware that it is not recommended to have more than 1000 node under single parent. However, We are planning to use Redirect Manager and redirect user to new pages with new structure. 

 

Approach:

 

Create 5000 dummy/empty pages in AEM in a flat structure. During migration, create actual pages in proper AEM structure (content/folder1/page1). Use Redirect Manager to map dummy page to actual content. 

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

The problem is less the performance of the repository, as there have been made a number of improvements in the past to handle that case. But before you hit the limits of the repository, your browser will stall while trying to display that amount of entries.

 

As this is a migration scenario and you just need to make old links still work, you should create a mapping from 

 

old url -> new url

 

and implement that mapping in the dispatcher as rewrite rules (or rewrite map). Then you are free to use the most appropriate content structure in AEM, and you can delegate all aspects of this mapping to the dispatcher/httpd.

 

View solution in original post

8 Replies

Avatar

Community Advisor

Yes, there will be performance issue, please check

https://cqdump.joerghoh.de/2015/07/09/1000-nodes-per-folder-and-oak-orderable-nodes/ 

 

you can add intermediate parents like /site/test/aa/ /site/test/ab/ ....../site/test/zz/



Arun Patidar

Avatar

Level 3

Thanks for your reply.

 

As per the article, It looks like read operation won't be an issue for 5000 nodes. In our use-case, after initial creation, we would be just reading the nodes. 

Avatar

Community Advisor

I have also seen the loading issues with node with many immediate children.

 

When you click on a parent node, the browser stops responding when it starts loading children nodes. This happens when you load from crx/de as well.



Arun Patidar

Avatar

Community Advisor

Hi @beast42 I agree with @arunpatidar. Having too many pages under single node will impact SEO, navigation while content authoring.

Avatar

Correct answer by
Employee Advisor

The problem is less the performance of the repository, as there have been made a number of improvements in the past to handle that case. But before you hit the limits of the repository, your browser will stall while trying to display that amount of entries.

 

As this is a migration scenario and you just need to make old links still work, you should create a mapping from 

 

old url -> new url

 

and implement that mapping in the dispatcher as rewrite rules (or rewrite map). Then you are free to use the most appropriate content structure in AEM, and you can delegate all aspects of this mapping to the dispatcher/httpd.

 

Avatar

Level 3

Thanks @Jörg_Hoh for the insights. 

Do you see any performance impact of having 5000 rewrite rules at dispatcher level? We can't have rewrite rules with wildcards since all old URLs have a flat structure. 

Avatar

Employee Advisor

Why don't you maintain all rewrites as a huge list of rewrites?

 

Rewrite /foo /newfoo.html
Rewrite /some/bar /newlocation/bar.html
Rewrite /baz.jpeg /content/dam/baz.jpeg

etc.