Missing JCR-SQL2 Queries from GraphQL Execution | Community
Skip to main content
J
JelenaS123
July 4, 2025
Solved

Missing JCR-SQL2 Queries from GraphQL Execution

  • July 4, 2025
  • 3 replies
  • 489 views

I'm currently testing the performance of GraphQL queries in AEM. As part of the analysis using the Query Performance Analyzer, I'm attempting to capture the underlying JCR-SQL2 queries from the QueryStats section in the AEM System Console.

However, for some of the GraphQL queries I successfully execute, I’m unable to find any corresponding JCR-SQL2 entries in the QueryStats. Instead, I consistently see a single query (red-marked on the ss) that appears unrelated to the specific query being executed:



Can anyone help me understand why the actual JCR queries might not be showing up?

Is it possible that certain GraphQL queries are resolved without triggering JCR-SQL2 under the hood?

Any insights or guidance would be greatly appreciated — thank you in advance!

 

 

 

Best answer by SantoshSai

Hi @jelenas123,

Since not all GraphQL queries in AEM rely on JCR-SQL2, you can analyze performance by:

  1. Disabling GraphQL caching temporarily via /system/console/configMgr/com.adobe.cq.graphql.persistentcache.impl.GraphqlCacheImpl to measure true response times.

  2. Using tools like Postman, GraphQL Playground, or curl with timing enabled to compare response times before and after changes.

  3. Enabling DEBUG logs for:

    • com.adobe.cq.graphql

    • com.adobe.cq.dam.cfm.impl.graphql

    This helps detect backend resolution times.

  4. Checking AEM system metrics (/status-heap, /status-slingthreads) for resource impact during query execution.

These steps should give you a good sense of whether optimizations are effective.

3 replies

SantoshSai
Community Advisor
SantoshSaiCommunity Advisor
Community Advisor
July 6, 2025

Hi @jelenas123,

I think, some GraphQL queries do not result in JCR-SQL2 executions, especially if the data is retrieved via direct resource access, in-memory resolution, or cached lookups rather than through the JCR query engine.

  • GraphQL resolvers (especially for Content Fragments) can resolve nodes using direct path-based access (ResourceResolver#getResource) without executing a query. These do not show up in the JCR QueryStats.
  • If you're seeing only a single red-marked query consistently, it might be part of the GraphQL schema introspection or fragment metadata resolution (eg. a one-time query fetching model definitions).
    It's not necessarily tied to your specific content data query.

You can try these steps to verify whether JCR-SQL2 is used:

  • Temporarily disable caching (/system/console/configMgr/com.adobe.cq.graphql.persistentcache.impl.GraphqlCacheImpl)

  • Force a query-like condition, eg. a GraphQL query with a dynamic filter:

    { contentFragmentList(filter: {title: {_expressions: [{value: "Test", _operator: CONTAINS}]}}) { items { title _path } } }

     

    These typically trigger JCR-SQL2 queries.

  • Enable DEBUG logging for:

    com.adobe.cq.graphql
    com.adobe.cq.dam.cfm.impl.graphql
    org.apache.jackrabbit.oak.query

  • Use Query Performance Analyzer to monitor runtime queries during GraphQL execution.

Santosh Sai
    J
    JelenaS123Author
    July 7, 2025

    @SantoshSai That makes sense, thank you for the explanation.

    Since the methodology I previously used to test GraphQL endpoints relying on SQL2 isn’t applicable here, do you have any recommendations on how to analyze their performance?

    I’m trying to determine whether optimization is needed, and if so, after applying changes, how to measure whether query performance has actually improved.

    SantoshSai
    Community Advisor
    SantoshSaiCommunity AdvisorAccepted solution
    Community Advisor
    July 7, 2025

    Hi @jelenas123,

    Since not all GraphQL queries in AEM rely on JCR-SQL2, you can analyze performance by:

    1. Disabling GraphQL caching temporarily via /system/console/configMgr/com.adobe.cq.graphql.persistentcache.impl.GraphqlCacheImpl to measure true response times.

    2. Using tools like Postman, GraphQL Playground, or curl with timing enabled to compare response times before and after changes.

    3. Enabling DEBUG logs for:

      • com.adobe.cq.graphql

      • com.adobe.cq.dam.cfm.impl.graphql

      This helps detect backend resolution times.

    4. Checking AEM system metrics (/status-heap, /status-slingthreads) for resource impact during query execution.

    These steps should give you a good sense of whether optimizations are effective.

    Santosh Sai
      Uppari_Ramesh
      Uppari_Ramesh
      July 11, 2025

      @jelenas123 If you talk about optimization , first thing you need to ensure is you should path based persistent queries instead of list based. You need to supply the fragment to the query via params then you will see very quick results but when you use List based queries then this will be the problem. Always use path based queries.

        kautuk_sahni
        Community Manager
        kautuk_sahniCommunity Manager
        Community Manager
        September 12, 2025

        @jelenas123 Hi there, wanted to follow up! Did you manage to resolve your question? If so, it would be great if you could share how you solved it, as that knowledge could guide others with similar challenges. Also, if one of the replies helped, even if it didn’t completely solve the issue but gave you the right direction, marking it as accepted will make it easier for others to discover. Your update ensures the conversation stays valuable for the whole community.

        Kautuk Sahni
        Terms & ConditionsAccessibility statement

        Loading footer...