agentsclimarketplace

Aem oak repository optimization

Skill prakash888kp/AEM-SKILLS/skills/tier-4-performance/aem-oak-repository-optimization

A curated catalog of Adobe Experience Manager (AEM) skills organized into tiers, with dependency chains and contribution guidelines.From the repository description

Install
npx -y skills add prakash888kp/AEM-SKILLS --skill aem-oak-repository-optimization

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.0 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it

AEM Oak Repository Optimization

Purpose

Optimize Apache Oak/JCR repository performance including index management, compaction, storage configuration, and query-level tuning for AEM's content repository layer.

When to Use (Triggers)

  • User mentions "Oak," "repository," "index," "compaction," or "JCR performance"
  • References to Lucene indexes, property indexes, or traversal queries
  • Questions about repository growth, segment store, or document store
  • Requests involving Oak query optimization, explain plans, or index definitions
  • Discussion of async indexing, reindexing, or index corruption

Core Capabilities

  • Design and implement custom Oak Lucene and property indexes
  • Configure online compaction and revision garbage collection
  • Optimize content node structure for repository performance
  • Diagnose and fix traversal queries using explain plans
  • Manage Oak index lifecycle (creation, updates, reindexing)

Domain Knowledge Required

Technical Foundation

  • Apache Jackrabbit Oak architecture (NodeStore, BlobStore, index subsystem)
  • Lucene index internals (analyzers, field types, aggregation, suggestions)
  • B-tree property indexes vs. Lucene full-text indexes
  • Storage backends: TarMK (segment), DocumentMK (MongoDB), RDB

AEM-Specific Context

  • OOTB Oak indexes in AEM (damAssetLucene, cqPageLucene, ntBaseLucene)
  • AEM index definition structure under /oak:index/
  • Async indexing lanes (async, fulltext-async, elastic-async)
  • AEM Cloud Service index management via Cloud Manager
  • Oak query engine query plan selection and cost estimation

Implementation Approach

Step 1: Query Analysis

Identify queries needing optimization.

  • Enable Oak query logging (org.apache.jackrabbit.oak.query at DEBUG)
  • Review error.log for traversal warnings (queries traversing >100K nodes)
  • Use Query Performance tool in AEM Operations console
  • Generate explain plans for slow queries

Step 2: Index Design

Create indexes targeting identified query patterns.

  • Define property index for equality/range queries on specific properties
  • Create Lucene index for full-text search or complex multi-property queries
  • Configure index rules with property definitions (ordered, analyzed, nodeScopeIndex)
  • Set appropriate includedPaths/excludedPaths to limit index scope

Step 3: Index Deployment

Deploy indexes safely with minimal disruption.

  • Create index definition under /oak:index/ with reindex=true
  • For Cloud Service: deploy via CI/CD pipeline with index migration
  • Monitor async indexing progress via JMX MBeans
  • Validate index is used via explain plan after deployment

Step 4: Repository Maintenance

Configure ongoing repository health operations.

  • Schedule online compaction (revision GC) during low-traffic windows
  • Configure checkpoint management and cleanup
  • Monitor repository size growth and blob store usage
  • Implement data store garbage collection for unused binaries

Step 5: Content Structure Optimization

Optimize node structure for repository performance.

  • Flatten deep hierarchies where possible (avoid >8 levels)
  • Use Oak-ordered indexes for sorted queries instead of in-memory sorting
  • Implement bucket patterns for nodes with >1000 children
  • Move large binary properties to separate nodes/data store

Quality Checklist

  • No traversal queries in production (all queries use indexes)
  • Custom indexes have appropriate scope (not over-broad)
  • Online compaction running successfully on schedule
  • Repository growth rate within expected bounds
  • Async indexing lag under 60 seconds during normal operation
  • Index definitions version-controlled and deployable
  • No duplicate or redundant indexes consuming resources
  • Query explain plans documented for critical queries

Related Skills

  • aem-query-optimization (query writing best practices)
  • aem-performance-tuning-profiling (overall performance)
  • aem-monitoring-alerting (repository health monitoring)

Example Use Cases

  1. DAM Search Performance: Create custom Lucene index for asset search covering metadata fields (dc:title, dam:scene, product SKU) with analyzers for partial matching and phonetic search.
  2. Content Migration Optimization: Pre-create indexes for content migration queries, configure bulk indexing mode, and manage post-migration reindexing with minimal impact on running system.
  3. Repository Size Management: Implement comprehensive repository maintenance including segment compaction scheduling, data store GC for orphaned binaries, and version purge reducing repository from 500GB to 200GB.

Notes

  • Never reindex lucene or damAssetLucene on production without scheduling downtime — it can take hours
  • AEM Cloud Service manages Oak indexes differently — deploy index definitions via CI/CD, not manual reindex
  • Property indexes are faster for simple equality queries; Lucene indexes are needed for full-text or complex conditions
  • Oak traversal limit is 100,000 nodes by default — queries exceeding this will fail in Cloud Service

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most performance cost skills give in ~1.0k tokens

Counted across 803 of the 1,058 authors here whose files we hold, read 2026-08-07

  • Keep skill files under 500 lines or tokensin 82 of 803, across 16 files
  • Use imperative form in instructionsin 80 of 803, across 9 files
  • Draft assertions while test runs are in progressin 75 of 803, across 9 files
  • Create two to three realistic test promptsin 74 of 803, across 9 files
  • Write skill descriptions to be pushyin 72 of 803, across 7 files
  • Save test cases to evals JSONin 72 of 803, across 6 files
  • Ask questions about edge cases and input formatsin 72 of 803, across 7 files
  • Save timing data immediately when runs completein 70 of 803, across 5 files
  • Include all trigger conditions in the skill descriptionin 69 of 803, across 3 files
  • Launch all test runs in a single turn or simultaneouslyin 69 of 803, across 3 files
  • Capture intent before writing a skillin 67 of 803, across 1 file
  • Import directly instead of barrel filesin 52 of 803, across 15 files

Said here and by no other author read

  • enable Oak query logging at DEBUG level
  • generate explain plans for slow queries
  • set includedPaths and excludedPaths to limit index scope
  • deploy index definitions via CI/CD pipeline
  • validate index usage via explain plan after deployment
  • schedule online compaction during low-traffic windows

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,861. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.