Overcoming the 1000+ node limit for cq:Page nodes in AEM 6.1

4
votes

We are currently building a large site using AEM 6.1 and will be migrating hundreds of thousands of records from an old RDMS-based system to AEM's JCR. We understand that the 1000+ node limitation does not apply to nodes with type nt:unstructured, but we are hitting limitation when using cq:Page nodes.

Our current site has a structure like this:

/
├── blog/
│   ├── some-blog-post
│   └── another-post
└── articles/
    └── some-article
    └── another-article
    └── ...
    └── ...
    └── ...

We have over 6000 articles in the articles subtree, and we must maintain the URL structure for the consumer facing site. We are using the Classic UI and we of course are running into performance issues when you expand the articles folder in the AEM Siteadmin. We could afford to split the articles into additional directories in the Siteadmin, but we would have to maintain the flat structure for our URLs.

What is the best way to do this in AEM? We can't do this in the dispatcher because the dispatcher would have no way to know where to map the request in the JCR hierarchy.

1
adobeaemslingjackrabbit-oak
which version of crx you are using? – awd
AEM 6.1 so Apache Jackrabbit Oak 1.2.2 – JStarcher

1 Answers

5
votes

If you split your content in a predictable way you can indeed use URL rewriting on the HTTP front-end to provide a flat URL structure.

As an example, /articles/s/so/some-blog-post can be reliably mapped to /articles/some-blog-post in both directions.

This would require some logic on the authoring side, to make sure your page paths are built according to such a rule.

Note that the usual way to handle this in blog-like content is to prefix the post paths with the creation date like 2016/02/29/some-blog-post which provides a nice and meaningful hierarchy.