Verifying minRecordLength impact and binary storage in AEM 6.5

[AbhishekTr1]

I'm working with AEM 6.5 and looking to optimize performance by configuring the minRecordLength property under org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.

The documentation recommends setting this to 100 to ensure binaries (like DITA files) are saved in the Data Store instead of the Segment Store for better performance.

However, I have a few questions:

1. How can I verify where the binaries are currently being stored — Segment Store or Data Store — especially for different file types and sizes?

2. If I don’t see the minRecordLength in the Felix Console (/system/console/configMgr), how do I confirm what value is being used by default?

3. After setting minRecordLength=100, is there a reliable way (via logs or tools) to confirm that new uploads are being saved in Data Store?

4. What metrics or logs should I track to evaluate performance improvements (e.g., segment size growth, compaction, GC)?

I’ve uploaded files like small.txt and used scripts: 

def assetPath = "/content/dam/test-upload/small.txt"

def originalNodePath = "${assetPath}/jcr:content/renditions/original/jcr:content"
if (!session.nodeExists(originalNodePath)) {
println "❌ Asset or original rendition not found at: ${originalNodePath}"
return
}

def node = session.getNode(originalNodePath)
def binary = node.getProperty("jcr:data").getBinary()
def binaryClass = binary.getClass().getName()

println "📂 Asset: ${assetPath}"
println "🔍 Binary class: ${binaryClass}"

if (binaryClass.contains("Segment")) {
println "📦 Stored in ➤ Segment Store (small file, below minRecordLength)"
} else if (binaryClass.contains("BinaryImpl")) {
println "🗄️ Stored in ➤ Data Store (file > minRecordLength)"
} else {
println "❓ Unknown binary storage mechanism"
} 

Result: 

Asset: /content/dam/test-upload/small.txt
🔍 Binary class: org.apache.jackrabbit.oak.plugins.value.jcr.BinaryImpl
🗄️ Stored in ➤ Data Store (file > minRecordLength)

to inspect the BinaryImpl class, but would appreciate a more complete validation and best practice guidance.

Any advice or script-based approach would be helpful.

[KimonP]

Hi @AbhishekTr1 ,

reg. your questions:

1. The script approach you took seems legit to me (class name and size check)

2. If minRecordLength is not shown, AEM is using the default value, which is 16,384 bytes (16KB). (see https://experienceleague.adobe.com/en/docs/experience-manager-65/content/implementing/deploying/depl...

3. I suggest enabling DEBUG/INFO logs for org.apache.jackrabbit.oak.plugins.blob (see https://developer.adobe.com/experience-manager/reference-materials/6-5/javadoc/org/apache/jackrabbit...)

4. Metrics to track:

• Segment store size (Should grow more slowly post-optimization)
• Data Store size (Should grow faster as more binaries are offloaded)
• Repo GC logs (Time and effectiveness of compaction)
• Asset upload times (should notice improved performance when storing large binaries)
• Memory/cache stats (via /system/console/memoryusage and JMX Beans, see https://experienceleague.adobe.com/en/docs/experience-manager-65/content/sites/administering/operati... )

Hope this gives some guidance on the way fwd!

[AbhishekTr1]

I investigated how binary storage works in AEM 6.5, particularly around the minRecordLength configuration and whether it needs tuning.

We have customBlobStore=true in our SegmentNodeStoreService config, meaning that binary content should be stored in a separate FileDataStore rather than inlined in the segment store.

As per the official Oak documentation (https://jackrabbit.apache.org/oak/docs/osgi_config.html), org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore minRecordLength has a default value of 100 bytes. This means:

• Binary content smaller than 100 bytes is stored inline (inside the segment tar).

• Binary content greater than or equal to 100 bytes is stored in the external datastore, unless overridden by other limits.

However, Oak has an internal hardcoded threshold of 16 KB (16,384 bytes) (Segment.MEDIUM_LIMIT) beyond which binaries can be stored as external blobs. This means:

• Even if minRecordLength is configured to a smaller value, binaries less than 16 KB are still stored inside the segment store.

• Only binaries larger than 16 KB are stored in the external datastore as actual blobs.

Relevant Oak issue explaining this: https://issues.apache.org/jira/browse/OAK-6911
This confirms that the minRecordLength setting applies only above Oak’s internal 16KB cutoff, and below that, inlining happens regardless of the value set.

To confirm this, I manually explored segment store from local setup using oak-run-1.22.16.jar explorer and observed that:

• Files below ~16 KB appeared directly stored in the segment, with the jcr:data property pointing to inline binary content (jcr:data = {BINARY} <SegmentBlob:ref:null.id:null:2 bytes> (b68dd114-aDe7-4ddo-a6be-S22 = STRING)

• For larger files, the jcr:data (<SegmentBlob; ref:(BlobStore not available); id:f9786d01272 f1bf26afe7cic7413df8caOe9b39a8ba77594b2b07f93820e6107764687;[Blobstore])property pointed to blob references, confirming that external FileDataStore was used.

So while minRecordLength=100 is tunable, it is effectively ignored for binaries under 16 KB due to the hardcoded limit in Oak....

Any suggestion it can tune less then 16kb will tuning will help in performance. And what  optimisation will happenn?