Don't Surrender to the Render
Thursday, March 24th, 2011 at 2:00pm -- Tim Reilly
As a support engineer, one of the most common questions I receive from customers is, "Why are my Pages taking so long to load?" A typical investigation into the matter first includes verifying that the application has enough resources allocated for optimal performance. Once I'm able to confirm that the system is configured properly, the next step includes a deeper look into the way the customer has integrated his or her site(s).
The first things I look for are any slow loading regions in the Page. This involves taking a look at each individual page region -- sometimes even removing Blocks and Formats one-by-one until the Page loads in an acceptable amount of time. Once this happens, it is easy to identify the problem Block and Format. So, why do very large Index Blocks cause Pages to load slowly? Consider this: have you ever tried opening a large XML document in a browser outside of Cascade Server? I've seen some XML files take upwards of 15 seconds to load while other (larger files) have caused the browser to crash. When you combine this with the fact that most pages consist of multiple Index Blocks (which also have to be transformed via XSLT or Velocity), it is easy to see how quickly a very large Index Block can hinder performance.
With the 6.8 release of Cascade Server we've made it easy to spot problem areas in Pages using Metrics. Now, when a Page is rendered in the system, the processing time for each Page region is measured and displayed in a new 'Metrics' menu which is available on the layout pane of the View tab. Clicking this item will show you the total render time for the Page along with a summary of how long each region took to render. Users can then click on the region name for a breakdown of how long the corresponding Block and/or Format took to render.
So, rather than having to remove Blocks and Formats from regions one at a time in order to isolate issues, users can now get a quick overview of how long each section of their page is taking to load. From there, steps can be taken to reduce the size of the offending Index Blocks and/or tune-up the Formats assigned to certain regions.
When limiting Index Block content, one approach is to look at the number of assets being indexed. Do you really need the Index Block to return data for assets that are 2-3 years old? If not, archive old assets in a separate Folder and/or make them non-indexed such that they won’t appear in the Index Block (thus reducing the size of the index). Another step would be to re-evaluate your Index Block settings to see if you are including page XML and/or Block XML inline. Whenever possible, un-checking these options will make for Index Blocks which are much smaller in size. Some may argue that they must have the page XML and/or Block XML setting enabled in order to retrieve data from the structured data content of their Pages. In these cases it makes sense to take a closer look at the implementation to see if any of those structured data fields can be converted into Metadata fields.
Formats can also be a source of additional rendering time. When using XSLT or Velocity, XPath is utilized to determine which XML nodes are used for transformation of content. Some methods within XPath are more efficient than others. One common instance of this is the use of “//” to search for specific content nodes within an XML structure. This often works but is generally not the most efficient way of getting specific content. The “//” is the shorthand of using the “descendant” axis which returns the XML node from anywhere within the XML structure. When getting the current page from an index block with current page appended, selecting “//system-page” seems a lot shorter than putting “/system-index-block/calling-page/system-page” but really the first way will render results a lot slower than the more specific path. This is because the “//” or “descendant” axis will traverse the entire XML node structure even if the XML node has already been found. It will even go within the “system-page” node checking to see if any of its nodes match the call. Meanwhile, the more specific path will only check the nodes and levels specified within the path.
This feature is a great help not only to our own support team but also to customers looking for answers as to why some of their Pages take more time to render. Metrics provide users with the tools they need to continually monitor how certain page configurations affect load times. From there, they can proactively address Index Block and/or Format issues to increase the performance of their site(s) within Cascade Server.
Category
- Product Upgrades