In large-scale Adobe Experience Manager (AEM) and AEM as a Cloud Service (AEMaaCS) implementations, repository performance is often influenced by how efficiently queries are executed and how frequently node validations are triggered.

One of the lesser-known but powerful performance tuning mechanisms in Apache Jackrabbit Oak is Direct Counts Configuration, provided via:

org.apache.jackrabbit.oak.query.SessionQuerySettingsProviderService.cfg.json

This configuration helps optimize query result counting, reduce unnecessary traversal overhead, and indirectly minimize repeated node-level validation pressure on the repository.

In high-volume DAM, reporting, and workflow-heavy systems, this optimization can significantly improve scalability and responsiveness.

What is Direct Counts Configuration in AEM (Oak)?

In Oak, when a query is executed, the repository often needs to:

• Traverse nodes
• Evaluate access controls
• Validate node visibility
• Count results (for pagination or reporting)
• Apply index constraints

By default, counting query results can be expensive, especially when:

• Large result sets are involved
• ACL evaluation is complex
• Deep node hierarchies exist
• Multiple principals are involved

Direct Counts Configuration allows Oak to bypass expensive counting logic for trusted users (typically service users), improving query performance.

Recommended OSGi Configuration Pattern (AEMaaCS)

In AEMaaCS, this configuration should be deployed via code:

ui.config/src/main/content/jcr_root/apps/<project>/osgiconfig/config.author/

File:

org.apache.jackrabbit.oak.query.SessionQuerySettingsProviderService.cfg.json

Example for Sample OSGi Config:

{
  "directCountsPrincipals": [
    "myproject-dam-report-service-user"
  ]
}

How Direct Counts Improves AEM Performance

1. Skips Expensive Query Counting Logic

Normally, Oak performs a full traversal or index-based estimation to calculate result counts.

With direct counts enabled:

• Oak avoids deep traversal for count operations
• Uses optimized index-level metadata where possible
• Reduces CPU consumption during queries

This is especially useful for:

• Pagination APIs
• Asset listing services
• Reporting dashboards

2. Reduces Repository Traversal Load

Counting operations often trigger additional node visits. With direct counts:

• Fewer nodes are visited
• Reduced repository read load
• Lower contention on large hierarchies like /content/dam

3. Improves Query Response Time

For trusted service users, Oak can:

• Skip permission-aware counting
• Avoid repeated access control evaluations
• Use faster count estimation paths

Result:- Faster response times for query-heavy operations.

4. Reduces Node Validation Overhead Indirectly

While Direct Counts Configuration does not disable node validation, it reduces the number of operations that trigger validation chains. This happens because:-

• Fewer nodes are traversed
• Fewer query results are individually evaluated
• Reduced interaction with repository state during counting

As a result:

• Lower load on validation pipelines
• Reduced ACL evaluation frequency
• Fewer transient node state checks

Important Note on Node Validation

Direct Counts Configuration does NOT bypass core repository validations such as :

• Node type constraints
• Property restrictions
• Access control enforcement
• Commit validations

Instead, it optimizes query-time counting behavior, reducing unnecessary traversal that indirectly triggers validation overhead.

5. Better Performance for DAM and Reporting Use Cases

In real-world AEM implementations, this configuration is especially impactful for:

DAM Queries

• Asset listing
• Metadata filtering
• Folder-level browsing

Reporting Systems

• Asset usage reports
• Publishing reports
• Audit dashboards

Workflow Systems

• Task dashboards
• Payload tracking
• Execution history queries

6. Reduced Load on Indexing and Query Engine

Oak relies heavily on indexes for query execution. Direct counts help by:

• Reducing fallback traversal queries
• Lowering index evaluation pressure
• Avoiding unnecessary node-level computation

This improves overall index efficiency.

When to Use Direct Counts Configuration

Use this configuration only for trusted service users, such as:

• DAM report service users
• Workflow service users
• Internal API users
• Batch processing users

Avoid enabling it for:

• End users
• Public search users
• External unknown principals

Benefits Summary:-

Below chart explains the benefits of AEM search query with and without direct count optimization.

Performance Benefits

• Faster query execution
• Reduced CPU usage
• Lower repository traversal cost
• Improved response time

Scalability Benefits

• Handles large DAM datasets efficiently
• Supports high concurrency workloads
• Reduces query bottlenecks

Repository Efficiency

• Reduced node traversal
• Lower validation pressure
• Optimized index usage

Best Practices

1. Use Only for Service Users

Restrict configuration to backend/system users only.

2. Combine with Proper Indexing

Direct counts work best when:

• Oak indexes are optimized
• Queries are properly structured

3. Avoid Overuse

Do not enable for all users — it may bypass important performance safeguards.

4. Monitor Query Performance

Use AEM Query Performance tool to validate improvement.

Real-World Example

In a DAM-heavy AEMaaCS environment:

• Millions of assets stored in /content/dam
• Frequent reporting queries
• High concurrency workflows

Before optimization:

• Query counts were slow
• Pagination APIs lagged
• Repository load increased during reports

After enabling Direct Counts:

• Report dashboards became faster
• Query latency reduced significantly
• Repository CPU usage dropped
• Node traversal overhead decreased

Conclusion

Direct Counts Configuration in Apache Jackrabbit Oak is a powerful but often underused optimization technique in AEM and AEMaaCS environments.

By enabling directCountsPrincipals in SessionQuerySettingsProviderService, organizations can significantly improve:

• Query performance
• Repository efficiency
• DAM scalability
• Reporting responsiveness

While it does not directly disable node validation, it reduces the operations that trigger expensive validation and traversal, resulting in a more efficient and scalable AEM architecture.

For enterprise AEM implementations, this configuration is a key part of advanced repository performance tuning strategies.