Pushing the limits on Template Builder’s estimates

­­­Lately I’ve been working with a client using Tridion in an interesting way. This client manages websites for hundreds of customers, each site being virtually identical. Of course, information such as the customer name, contact info and store hours, along with dozens of other bits has to be customized for each site. One of the ways they manage this unique information led me to a useful discovery on how Template Builder handles large packages. Hopefully by sharing here I can save someone else going on the same wild goose chase I did.

In order to populate the rendered pages of each site, my client places all the pertinent information on the package when publishing a page. This way they can centralize all of the fields that need to be updated for a customer to a single component. Then a Template Building Block (TBB) grabs the information and fills in the blanks on the page, like a robotic Mad Lib.

This leads to the package for each page getting relatively large as it can have hundreds of items, which means hundreds of entries in the XML that makes up the package. When this page is run in Template Builder we see something I didn’t expected:

TBBs in Template builder showing discrepency in publishing time

As you can see, each TBB in “Load Code Snippets” runs quite quickly, much less than a second generally. But when viewed as a whole, “Load Code Snippets” takes much longer. Multiplied across a few compound templates per page, a few dozen pages per customer, and a few hundred customers, this unaccounted for time could become quite a problem when publishing our site, right?

Before answering that question, let me explain what’s causing this gap. As you may have guessed, it’s the large publishing package that’s moving through Template Builder. The larger the package, the longer it takes for Template Builder to pass it around between TBBs. The quickest way to get a huge package (publishing package that is, for other types check your spam folder) is to have many items. This is because each item, even if it’s only a single character adds a few lines of XML to the package. A thousand items, each a single character long is significantly larger than a single item with a thousand characters.

With this in mind and eager to save my client hours and hours of publishing time, I set out to do two things:

  1. Reduce the number of TBBs on each Page Template – by cutting down the number of TBBs our large package had to be handed between we’d cut down on tonnes of time
  2. Consider adding our items as long, comma-separated strings – even with the extra time it would take to parse our giant string, given the time it was taking to pass around our large package, I figured we’d still come out ahead

After spending some time getting together a proof of concept for these two modifications I ran my page through Template Builder and saw a huge improvement, on the scale of 40% reduction of publishing time!

However, I was in for a surprise when I went to publish my test pages in Tridion. You see, Tridion publishing had always been much faster than in Template Builder, but I still expected a proportional improvement to publishing time. Imagine my disappointment when my changes barely put a measurable dent in publishing time. In fact, the publishing time in Tridion very closely correlated to the sum of each individual TBB’s time measurement in Template Builder, both before and after I made my modifications, meaning no matter what I did, “Load Code Snippets” in my image above took about 8s to publish in Tridion, rather than 24s.

What does this mean? It means that Template Builder’s time estimates start to break down as the size of your publishing package increases and we shouldn’t be too concerned if we see large publishing times in Template Builder until we make sure Tridion is taking the same amount of time. And it means, at least for this case, the size of your package really doesn’t matter.

5 thoughts on “Pushing the limits on Template Builder’s estimates

  1. Good find, and indeed, the times in Template Builder have always been explained as an indication of how long a certain TBB takes compared to others. The times mentioned in there really belong to the Template Builder and actual publishing times will certainly be less. In your case the Template Builders execution times were even less relevant than they normally are…

  2. Interesting discovery–and it’s nice to see attention paid to performance (rather than “it’s taking a long time”). I can see how having the client-specific details embedded into each page, it’s hard to separate these from the rendered templates.

    Alternatives could be publishing resource or XML files so that the values aren’t in the CMS template package. However, the trade-off is the logic and time (and probably caching) to display those values dynamically at runtime.

    Finally, regarding huge packages, should I preempt any “that’s what she said” jokes? This is probably the second Tridion post alluding to male body parts.

  3. Thanks Bart, I’d never had it explained to me that way, so I was relying too closely on the times in Template Builder. Good to make that distinction.

    Alvin, we actually do a mixture of what you suggest, pushing out some values as XML and some in the method I outlined, depending on how they’re used and factoring in the trade-offs you mentioned. Glad to hear we’re on the same page!

  4. Pingback: Reusing template designs | SDL Tridion Developer

  5. Pingback: Timing templates with a stopwatch | SDL Tridion Developer

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>