Structuring your JCR workspace

JCR is designed to store hierarchical structured data and it doesn’t do so well with flat hierarchies. Though there is technically no limit to the number of subnodes under a parent node, practically speaking, you’ll encounter problems over a certain number.

Rule of thumb

If you have more than a few hundred child nodes under a single parent node, you may encounter problems and should consider restructuring the workspace.

What are some issues I may encounter?

If you have a poorly structured JCR workspace, you may encounter things like:

  • Poor app performance (e.g., slow load time, slow to fetch data)

  • Lucene indexing issues

  • Publishing problems

Best practices

To avoid the aforementioned issues, you should consider the following best practices when structuring your JCR workspace.

Limit child nodes

Any workspace with more than 500 child nodes should be restructured to keep it under 500 child nodes for any parent node.

Click to see a Groovy script to split flat structures into folders 
folderSize = 100
workspace = "tours"
nodeType = "mgnl:content"
rootPath = "/magnolia-travels/"
query = "select * from [" + nodeType + "] WHERE ISDESCENDANTNODE('" + rootPath + "')"
session = MgnlContext.getJCRSession(workspace);
manager = session.getWorkspace().getQueryManager();
nodes = manager.createQuery(query, "JCR-SQL2").execute().nodes;
folderName = 0
nodesInFolder = 0
while (nodes.hasNext()) {
    folderPath = rootPath + folderName
    NodeUtil.createPath(session.rootNode, folderPath, "mgnl:folder");
    node = nodes.next()
    newPath = rootPath + folderName + "/" + node.name;
    if (node.path != newPath) { //repeatable script
        session.move(node.path, newPath);
    }
    if (nodesInFolder++ > folderSize) {
        nodesInFolder = 0
        folderName++
    }
}
session.save()


Time-related content

If your JCR content is time-related, consider using a folder structure like /<year>/<month>/<day of month>/<hour>/<minute>/<second>/<child> to distribute child nodes across a deeper structure and limit the number of child nodes in a single folder.


Naming conventions

If your JCR content has a name, consider using a folder structure like /<letter range>/<initial letter>/<children>, for example /a-d/a/<child with name beginning in a>. Keep it under the 500 limit for child nodes in a folder.

Workaround

If you’re still having issues navigating through a tree view in the AdminCentral app, try increasing the size of the Jackrabbit caches to avoid retrieving many nodes from the JCR repository database.

Set with java properties
org.apache.jackrabbit.maxCacheMemory: default 16777216 (1)
org.apache.jackrabbit.minMemoryPerCache: default 131072 (1)
org.apache.jackrabbit.maxMemoryPerCache: default 4194304 (1)
1 Value listed in bytes.
Set with JVM command line
-Dorg.apache.jackrabbit.maxCacheMemory=268435456 (1)
-Dorg.apache.jackrabbit.minMemoryPerCache=1048576 (1)
-Dorg.apache.jackrabbit.maxMemoryPerCache=67108864 (1)
1 Value listed in bytes.

References

Feedback

DX Core

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the Performance tuning guide docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules
6.3 beta
X

Magnolia 6.3 beta

Magnolia 6.3 is in beta. We are updating docs based on development and feedback. Consider the 6.3 docs currently in a state of progress and not final.

We are working on some 6.3-beta known issues during this phase.