GraphQL query shows up in Query Recorder logs with large scans, but the query should be performant | Community
Skip to main content
P
Preston-3
Level 4
March 11, 2026
Question

GraphQL query shows up in Query Recorder logs with large scans, but the query should be performant

  • March 11, 2026
  • 2 replies
  • 12 views

We have some GraphQL persisted queries that show up in the AEM Query Recorder logs as having large scans to return a single result. Here’s an example of what we see in the logs. 

 

[72.135.49.53 [1773258109390] POST /graphql/execute.json/mycompany/getProductDetails HTTP/1.1] org.apache.jackrabbit.oak.query.stats.QueryRecorder count:	2400	query:	SELECT main.* FROM [dam:IndexedFragmentData] AS main WHERE ISDESCENDANTNODE(main, 'x') AND main.[@string@model] = 'x' AND (name(main) = 'x') AND ((ISDESCENDANTNODE(main, 'x')) AND (main.[string@serviceCode] = 'x') AND (main.[jcr:primaryType] IS NOT NULL) AND (main.[jcr:primaryType] IS NOT NULL) AND (main.[jcr:primaryType] IS NOT NULL)) ORDER BY main.[jcr:path] OPTION (INDEX TAG[contentFragments], TRAVERSAL FAIL)

What’s jumping out to me is the “QueryRecorder count: 2400” when there is only 1 record returned. And when I run the same query locally and look at its performance in the Query Performance tool it shows as scanning only 1 row. So I’m wondering how this could happen. Any help would be appreciated as we don’t have access to the Query Performance tools on Publish in Cloud environments. I have opened a ticket with Adobe as well, but I’m curious if anyone has seen this. 

    2 replies

    AmitVishwakarma
    Community Advisor
    AmitVishwakarmaCommunity Advisor
    Community Advisor
    March 12, 2026

    Hi ​@Preston-3 

    You're reading that QueryRecorder line correctly, but the count: 2400 part is easy to misunderstand:

    [... ] org.apache.jackrabbit.oak.query.stats.QueryRecorder 
      count: 2400 
      query: SELECT main.* FROM [dam:IndexedFragmentData] ...

    That count is the cumulative execution count of that exact SQL2 statement on that pod, not "rows scanned for this call".

    So in your case:

    • The GraphQL persisted query returns 1 record.
    • Locally, the Query Performance tool shows scan = 1 row for a single run (using the proper CF index).
    • On Cloud Publish, QueryRecorder count: 2400 just means:
      • this same persisted query has been executed ~2400 times since the pod (or QueryRecorder stats) started.

    It does not mean "this one request scanned 2400 nodes".

    How to check if there's a real performance problem

    Ignore count for performance diagnosis and instead look for:

    1. Traversal / read-limit warnings in logs, e.g.
      • Index-Traversed XXXXX nodes…
      • The query read or traversed more than 100000 nodes…
    2. Whether the query is using an index (your example has
      • OPTION (INDEX TAG [contentFragments], TRAVERSAL FAIL), which is ideal).
    3. Query Performance on a representative, large-ish environment:
      • Check plan, nodes scanned/read, not the count metric.

    If there are no traversal/read-limit warnings and the plan uses the CF index with low node scans, the query is healthy; a high count just reflects that it's popular.

    Amit Vishwakarma - Adobe Commerce Champion 2025 | 16x Adobe certified | 4x Adobe SME
    VishalKa5
    VishalKa5
    Level 5
    March 12, 2026

    Hi ​@Preston-3 ,

    In Adobe Experience Manager (AEM) Cloud Service, this can happen due to how Oak records query scans.

    Key Points:

    1. QueryRecorder count shows the number of nodes scanned, not the number of results returned.

    2. Local vs Cloud difference may occur because indexes or content size differ.

    3. GraphQL queries use the contentFragments index, and if it is not fully optimized, Oak may scan more nodes.

    4. Publish environments usually have more data, which can increase scan counts.

    5. Since Query Performance tools are not available in Cloud Publish, raising a ticket with Adobe is the correct step.

    Conclusion: A large scan count in logs does not always mean poor performance; it mainly indicates how many nodes Oak checked during the query.

    Thanks

    Terms & ConditionsAccessibility statement

    Loading footer...