Does publishing a Component linked to many Dynamic Component Templates lead to publishing performance issues?
I recently ran into a scenario where, due to an update to business requirements, I had to change Component Templates from statically embedded to dynamic. In my case there were 14 different CTs linked to the same Schema. This means that when 1 Component is published there are 14 Component Presentations being rendered and sent to the Broker. The question then arose, does this kind of a design lead to publishing performance issues?
My hypothesis was that there would be a massive problem with having so many CTs linked to the same schema, publishing these types of items would be dead slow and possibly result in a failure.
Tridion version is 2011 SP1 HR2.
Test 1: Publish 1 Component having many associated CTs and measure the end to end time it takes to resolve, render, transport and deploy.
Test 2: If Test 1 is successful, publish many (42 [get it? 42]) Components at once measuring performance in terms of time.
To my surprise, end-to-end publishing did not take any more time than when only one Dynamic CT was associated with the Schema.
Publishing 1 Component started at 6:02 PM. Publishing completed several seconds later at 6:02 PM. The Transaction Details screen showed 14 items processed successfully.
For my second test I sent 42 Components to the Publishing Queue. This equates to 588 DCPs rendered and sent to the Broker (42 * 14 = 588). The test started at 6:43 PM. By 6:46 PM all items had been successfully published and deployed. Note, no one else was publishing on the system at the time.
Having many Component Templates linked to the same schema creates a Component Presentation for each template, however, this does not seem to significantly diminish publishing performance. If it does, than this performance hit is negligible.
This may be due to having the most performance intensive operations happening only once in the CM. Hence, once all the package items are retrieved and fully resolved, they are cached. It is also possible that resolving and rendering for each item may happen simultaneously in separate CPU threads not displayed on the Transaction Details screen. One thing to note though, Tridion’s templating follows a Single Threaded Apartment model, so the use of multiple internal threads seems to be unlikely (a question for R&D folks over beers sometime).
Folks at SDL R&D have certainly thought through and taken care of this scenario. So we, the implementors, can take comfort in knowing that the product “just works”.