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.
Solved! Go to Solution.
Views
Replies
Total Likes
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.
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/
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.
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.
Hi @beast42 I agree with @arunpatidar. Having too many pages under single node will impact SEO, navigation while content authoring.
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.
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.
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.