Understanding the Explain Query Tool

The Explain Query Tool essentially breaks down and explains the steps and processes a query goes through in AEM. Think of it as a ‘debug mode’ for your search queries. It provides insights into how the system interprets the query, the indexes it leverages, the estimated cost of the query, and other essential metrics.

Benefits of Using the Explain Query Tool:

• Performance Analysis: By revealing how the system interprets and executes the query, developers can identify bottlenecks or inefficiencies.
• Better Indexing: Developers can understand which indexes are being used and optimize or create new ones accordingly.
• Debugging: It becomes easier to pinpoint issues in complex queries when developers can visualize each step.

Using Explain Query Tool with Different AEM Backend Search APIs

1. SQL2:

SQL2 is the SQL-like query language used in AEM, and it’s one of the primary ways developers retrieve data from the JCR (Java Content Repository).

How to Use:

Navigate to the AEM Query Performance Tool, and select on the “Explain Query” tab. Choose the “Language” drop down to be SQL-JCR2, and input the JCR-SQL2 query that you are trying to test. Now click on explain, and you’ll see a breakdown of the query’s interpretation and execution.

AEM Query Performance Tool
http://localhost:4502/libs/granite/operations/content/diagnosistools/queryPerformance.html

2. Query Builder API:

Query Builder API allows developers to build search queries programmatically using a more intuitive map-based syntax. It abstracts some complexities of the JCR, offering a more accessible way to retrieve content.

How to Use:

Navigate to the AEM Query Performance Tool, and select on the “Explain Query” tab. Choose the “Language” drop down to be Query Builder, and input your Query Builder query that you are trying to test. Now click on explain, and you’ll see a breakdown of the query’s interpretation and execution.

AEM Query Performance Tool
http://localhost:4502/libs/granite/operations/content/diagnosistools/queryPerformance.html

3. XPath:

XPath is another way of querying the JCR in AEM. While it’s less commonly used than SQL2, it can be more expressive and powerful for certain hierarchical data structures.

How to Use:

Navigate to the AEM Query Performance Tool, and select on the “Explain Query” tab. Choose the “Language” drop down to be XPath, and input the XPath Query that you are trying to test. Now click on explain, and you’ll see a breakdown of the query’s interpretation and execution.

AEM Query Performance Tool
http://localhost:4502/libs/granite/operations/content/diagnosistools/queryPerformance.html

Other Options for the AEM Query Performance Tool

1. Include Execution Time: Execution time will be reported after running the query. Please note that long running queries will report an explanation with a delay.
2. Read first page of results: The first 20 results will be read after running the query. Please note that long running queries will report an explanation with a delay, and the overall execution will timeout after 60 seconds.
3. Include Node Count: The node count is calculated by iterating the full result set of the query. Please note that long running queries will report an explanation with a delay, and the overall execution will timeout after 60 seconds.

AEM Query Performance Tool
http://localhost:4502/libs/granite/operations/content/diagnosistools/queryPerformance.html

Conclusion

The Explain Query Tool in AEM is a powerful ally for developers, especially those heavily invested in ensuring the performance and accuracy of their search queries. By familiarizing oneself with this tool across the various backend search APIs, developers can optimize their AEM platform for both performance and maintainability, ensuring that the content delivery is swift and relevant.

The post Optimizing & Debugging Search Queries, Explain Query Tool AEM appeared first on Sourced Code.

Sling Models field injectors are used to support injection of AEM Library-specific context objects. For example, @ScriptVariable SightlyWCMMode will inject the WCMMode object, @ScriptVariable Resource will inject the current resource object, and @ScriptVariable Style will inject the Style object. These objects are typically stored within the object, so it can be later used to construct the Sling Model’s properties to make available to the context who’s calling it.

With the Apache Sling Model’s injector specific annotations, we are able to inject Sling Objects, AEM Services, OSGI Components, etc… directly into the context of the Sling Model easily without much hassle.

The Sling Model constructor injection is also supported (as of Sling Models 1.1.0), and its documented that it does not store the reference to the adaptable, lets test this out.

In this article, we will test the Sling Model memory consumption with two scenarios:

1. Test 1: Sling Model Field Injection
2. Test 2: Sling Model Constructor Injection
3. Conclusion

Test 1: Sling Model Field Injectors

I have 3 injected AEM objects to be stored in my class variables into my Sling Model via field injection; another 3 variables used to expose data to the calling context. Each AEM objects will then be used in the @PostConstruct method, where data would be extracted from each object, and set in the class variables for exposure to the calling context.

I then ran a test for getting the bytes in size for a specific object using the Lucene’s until RamUsageEstimator.

The memory byte size of the Sling Model adaptable object is 40.

MyModel.class : RamUsageEstimator Results:

MyModel.class:

Test 2: Sling Model Constructor Injection

I have 3 injected AEM objects via Constructor Injection; another 3 variables used to expose data to the calling context. This time, I am not storing the AEM objects in as class variables. We can definitely see a change in byes size here.

The memory byte size of the Sling Model adaptable object is 24.

MyModelConstructor.class : RamUsageEstimator Results:

MyModelConstructor.class:

Conclusion

An AEM object that has been field injected into a variable that is only being minimally used holds onto memory which will/can be be wasting resources. If AEM objects are not needed, then the Constructor Injection method can be appropriately used.

It’s not rocket science. We see the results! Test 2 has less instance variables than Test 1; of course Test 2 will have a smaller Object (in byte size) than Test 1.

My only recommendation is this. When you are using AEM Objects, ask yourself, how is this Object being used?

This article highlights why Sling Model Constructor Injection via constructor is useful in our AEM development.

The post AEM Sling Model Field Injection vs Constructor Injection Memory Consumption appeared first on Sourced Code.

Especially with AEM enterprise websites, our motive is to deliver high-performance websites. Us as developers, we try our best to keep the code our clean and optimum. When it comes to creating new AEM components, instead of waiting for the batch of approved non-released code to be deployed into a performance testing environment, you can monitor the performance of your AEM components beforehand in local author.

Quickly view and monitor the performance of your component’s Sightly front-end logic and Sling Models back-end logic has never been so easy!

How to Review Server-Side Computational Time with “Developer Mode”

“Develop Mode” lives in authoring AEM environment, inside of the editable page.

1. 1. Visit any page that you would like to measure. Ensure the targeted component sits on the page, and if not, add the component to the editable page. http://localhost:4502/editor.html/content/we-retail/language-masters/en.html
   2. Click on the tool-bar drop-down selector, and select on “Develop”.
      
   3. The page is reviewed with a side-panel which includes the component tree; the component tree is populated structure of all the components that live within the targeted page. Immediately you can see the server-side computational time. This information is extremely useful when you are trying to optimize your AEM website. The metric used here is ms for milliseconds and s for seconds. As you can see in the image provided below, Page .033s indicates that the entire page takes 1/3 of a second to load all the components.
      

      
      
      

   4. Along with a grouped server-side computational time, Individual components computational time will also be displayed. In the screenshot below, we are taking a look at the performance of the header component.
      
   5. Hooray! You Have Completed this Tutorial. As an extension to this tutorial, we will learn about the “view details”, “edit script”, and also the “errors” option.
      
      Buttons Legend:
      View Details: a link to a list that shows all the component scripts used to render the component, and also the repository content path for this specific component.
      Edit Script: a link that opens the component’s script in CRXDE Lite.
      Component Details: a link that takes you to the component details page.

The post Improve Performance of AEM Components During Development Phase appeared first on Sourced Code.