In part III of this series, we reviewed what APM information is captured by AEM java agents, and the problems it causes for transaction names. In part IV, we will learn how to set our own transaction names for APM software.
How To Set Transaction Names for APM Software
How does one go about solving the problem of generic transaction names? Most APM vendors have a way to tell their software what a transaction should be named when a page or servlet is rendered. Since Sling uses a series of filters to render content, a Sling filter can be added to the request processing pipeline to figures out what type of page or servlet is being rendered and tell the APM vendor what name to use for the transaction. Freed Technologies has created the open source Sling APM Framework to solve this problem. Using our framework, one can use the cq:template or sling:resourceType as the transaction name.
After installing the Sling APM Framework and configuring it to log template names as the transaction name, APM vendors categorize transactions based on the cq:template or servlet that was used to render the page. Here is how it looks in New Relic
Here is how it looks using Elastic APM:
Now these are some great metrics to analyze!
Instead of storing any AEM request as a generic transaction name, the APM software now logs the cq:template used to render a page or servlet name. Since We.Retail uses the cq:template as a way to segment different types of pages, one can look at how an application is performing for each cq:template used on the site. In addition, when an http request resolves to a sling servlet instead of a resource type, the transaction is named for the servlet that was called, which means servlets are tracked uniquely. For example, in the screenshot for Elastic APM above, the most expensive transactions are named:
com.adobe.granite.contexthub.impl.ConfDeliveryServlet– Servlet used to render contexthub data via ajax callcom.adobe.cq.commerce.impl.RelatedProductsServlet– Servlet used to render related products via ajax call/conf/we-retail/settings/wcm/templates/hero-page– pages rendered using the hero template/conf/we-retail/settings/wcm/templates/product-page– pages rendered using the product page template
One can now look at which types of pages get the most traffic, take the longest to render, and also cost the most from a cpu perspective, all of which is incredibly helpful when looking for performance bottlenecks. For example, the context hub ajax call is by far the most expensive request to AEM from a response time and throughput perspective. If this were a live AEM implementation, that would be the first performance bottleneck to investigate.
But wait, it gets even better!
Now that transactions are named after the cq:template or servlet used to render a page, one can view details of response times of components contained within the request to find code bottlenecks of components within a page.
New Relic creates a chart that displays the average response time of the components within a transaction:
Elastic APM will show individual AEM requests for a transaction. If one clicks on a sample, they can see detailed information about the timing of the components within the page:
For example, by looking at the Elastic APM transaction data, one can see that when rendering a hero-page template, it then renders a responsive grid, which includes the navigation component that has a variety of sub components.
When a bottleneck is discovered in a template, an engineer can drill into the details of the transaction to find the slowest components within it.
Ready to get started with your own custom transaction names? Try out Version 1.0 of the Sling APM Framework . Detailed instructions on enabling the framework in your AEM environment are included in README.md.
Are you new to APM with AEM and are looking for assistance? Contact Freed Technologies to learn how we can kick start your APM efforts for AEM.
