Since Kentico Xperience 13 Refresh 1 was just released, it’s the perfect time to look at the enhancements that have come to the platform! It offers a lot of exciting product enhancements for marketers, content managers, and developers. Let’s take a quick look at one that’s extremely helpful to software developers working on building and maintaining Kentico Xperience applications—enabling the Debug module features for the Content Delivery (MVC) application.
When Kentico 12 MVC was released, there was some inconsistency in the Content Management application’s features and interface. Since the Portal Engine development model was still available, not all features in the application worked the same way for Portal Engine and MVC sites.
The Debug module was among those, and it provided valuable insights into the performance of a site and could help developers diagnose issues—especially when a site had been deployed and debugging in Visual Studio wasn’t going to be an option. This module enabled the ability to see live snapshots of SQL queries, cached data, and K# Macros. With the addition of MVC, these features only applied to the Content Management (Web Forms) application, not the Content Delivery (MVC) application.
However, with Kentico Xperience 13.0 Refresh 1, this debugging information is now available for both applications!
For those new to Kentico Xperience, we can take a look at how to enable them, and then we’ll explore the different kinds of insights we can gain when using them with the Dancing Goat demo site.
SQL Debugging
We can enable SQL debugging by opening up the Content Management application and navigating to the Settings module.
The option is found under Settings -> Content -> System -> Debug -> SQL queries -> Enable SQL query debug.
Once we have this enabled, we can navigate to the Debug module and view the SQL queries -> Live site tab.
Make sure your Content Delivery (MVC) application is running and load a page in the browser. Now click the “Live site” navigation link again to reload the list of executed queries.
There’s a lot of information here, and most of it should be familiar to a developer that understands how SQL database queries work.
The key data points to notice are the “Duration” of each individual query, the size of the resulting data set of each query, and the total number of queries required to load the data for a given URL.
If we load the Dancing Goat home page with an empty cache, we can see a total of 55 queries are executed to get all the data for the page. When we then reload the page, only 13 queries are executed due to the number of cached items from the previous page load—that’s a significant difference.
And while these counts don’t necessarily include the queries for displaying all the images on the page or any updates to the database for activity logging, it does give a good idea of the impact that caching can have on our sites loading speed and the cost of infrastructure that we might need to deploy a site to production without effective caching implementation.
Another use for SQL debugging is copying the executed query and pasting it into our preferred MS SQL editor (I like to use the cross-platform Azure Data Studio). Since the SQL that is logged to the Debug module is the exact SQL query that is executed, include all parameterized values, the result we see in our editor should match what our application receives to display on the site.
We should pay attention to just how much data is being queried and decide if all of it is needed. Optimizing queries can have a two-fold performance impact—there is less data being transferred from the database to our application and also because there is less data being cached in-memory.
That brings us to the next Debug module feature: Cache item debugging!
Cache Item Debugging
Cache item debugging doesn’t need to be enabled the way SQL debugging does.
If we look at the Cache item list (Cache items -> Live site), we can see everything that is currently cached in the Content Delivery application.
We can search for cache items by their cache item name (key) and then view the contents to see what exactly is cached!
The dependency keys for each cached item are also listed. This list tells us what could be updated in the database that would cause that particular cache item to be removed from the cache (because it would then be outdated). The details of the Cache item also show the expiration date.
In the case of Cache items created by Kentico Xperience’s internals, we can be assured that there’s a logical cause for each entry. The real benefit of this debugging feature is seen when we are caching in our custom code.
Since cache invalidation is considered one of the two challenging problems in computer science, it’s no surprise that developers often find themselves wondering why out-of-date information is being used in their applications.
While sometimes this is because we were querying the cache when we meant to query the database instead, the more common cause is that we thought the cache would be empty because data had been updated, and instead, the cache is still populated with the old data. This is the perfect time to go to the Cache items list, find the item that should not be there, and view its cache dependency keys, which we likely set incorrectly!
Cache Access Debugging
While Cache item debugging is useful for knowing when something has been inserted into the cache, Cache Access debugging tells us when something was retrieved from the cache.
Cache Access debugging can be enabled in the location as the other debugging features (Settings -> System -> Debug -> Cache Access -> Enable cache access debug).
If we come up with good, unique Cache item names, then we can browse through the list of accessed Cache items and have a pretty good idea of what was trying to retrieve each cached item—if we need more information, the Context column shows a full stack trace.
We can view the details here of each Cache item, just like Cache item debugging.
It’s not enough to look in the Cache items—that doesn’t tell us if the page we loaded was actually using the cached data. We can think about the SQL, Cache item, and Cache Access debugging like a formula:
Content on Page = Cache Access + SQL
Or
SQL = Cache items—Cache Access
All of these tools work together to give us the information we need.
Macro (K#) Debugging
While our use and reliance on macros might have lessened in the world of MVC development with its strong typing, Page Builder components, and explicit querying, that doesn’t mean Kentico Xperience doesn’t still use macros where appropriate—even in the Content Delivery application.
Most of the time, with Macro debugging enabled, we’ll see macros evaluated to determine the <title> of the page.
This is because in Kentico Xperience’s settings (Settings -> Content -> Metadata -> Page title format), the formatting for the page’s title is defined with a K# macro!
That said, there are many other situations where it might not be obvious that macros would need to be evaluated. Take, for example, in the Dancing Goat demo site when visiting the Store page. Here, prices need to be determined for the products displayed. The product prices might be associated with discounts defined in the Content Management application.
The identifying information is found in the macro Expression. We see “ProductIsOneOf” and “Hario Vacuum Pot.” Under the Context, we can see a stack trace where CatalogPriceCalculator.GetPrices() is being called—that looks like it might be a Catalog Discount.
And that’s exactly what we’ve found!
Macro debugging can be used in combination with Cache and SQL debugging to determine where performance bottlenecks might be in our sites. Imagine a page that lists 50 items, each needing a macro execution to determine a value, without any caching and data being over-retrieved from the database. Yikes.
Conclusion
It’s easy to be overwhelmed by the complexity of modern web applications. Fortunately, Kentico Xperience has always provided tools and features for Marketing Experts, Content Managers, and Software Engineers to bring value to their website’s visitors.
Now, with Kentico Xperience 13 Refresh 1, we have access to the data we need to solve problems and improve site performance, both in ASP.NET MVC5 and ASP.NET Core applications. We might not use the Debug module every day, but we’re glad it’s there when we do!