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?
Hypothesis:
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. Â
Experiment Procedure:Â
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.
Results:
To my surprise, end-to-end publishing did not take any more time than when only one Dynamic CT was associated with the Schema. Â
Test 1:
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.
Â
Test 2:
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.
Conclusion
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”.
Nick I kind of disagree with your finding. There is definitely a hit in performance of publishing.
1. Render : This takes lot of time. In your case it has to render all the 14 Templates for that component which takes time even at the fast it adds one second.
2. Resolving/Transporting : This is not that noticeable but differs from template to template (DWTs) – Imagine short DWT with title/short image vs. details DWT with more images and related components. The package is slightly big, but not considerable
3. Deployer and Storing to DB Borker: Here we see another hit, now it has persist 14 records to component presentations and also create the link info entries for link resolving.
so overall.. We observed some performance hit as you have more Dynamic CTs with a schema and wondering why it is different (goo thing thought :)) in your case. What I heard from PS/R&D it will take more time you have more CTs because more rendering and more persisting to DB
Hi Kaylan, what you describe in your 3 points is exactly what I expected in my hypothesis and I was surprised (to the extent of being inspired share my findings). The experiment I conducted showed the contrary. One thing I’d like to add is that the schema used contains several nested components, so there is a descent amount of logic in each CT.
Regarding your point #1: It is logical that there is a performance hit with each new CT associated to a schema, however, my experiment showed that it is negligible.
Point 2: yes, as you’ve stated, this is not that noticeable.
Point 3: to an enterprise level application server running deployer logic and to an enterprise level database, such as Oracle or SQL Server, persisting a few hundred records in an asynchronous job, such as that of deployment, is completely negligible in terms of performance.
Please also take note of my second test where I sent 42 Components to the Publishing Queue, resulting in 588 DCPs sent to the Broker. There was no problems there at all.
Would you please quantify your statement: “observed some performance hit”. The experiment I’ve conducted above shows that the number “some” is very negligible.
Good stuff Nick. Its always the best approach to just try stuff out if you have a concern! I agree with Kaylan to some extent – publishing more CTs will always have some performance hit – templates do not get rendered by magic. How extensive this is depends on your Tridion version, templating technology and how complex the templates are (Dreamweaver TBBs in version 5.3 containing nested loops and conditionals were very slow compared to pure .NET TBBs, or even VBScript)
I think the core does some caching at Publish Transaction level as well, so I would be interested to see if you could get improved performance by (programatically) creating a single Publish Transaction for your 42 components – or (if you are using SDL Tridion 2013), put them all in a bundle and publish the bundle.
@Will, thanks for your comment. I’ve updated the post with Tridion version number (2011 SP1 HR2). I’m not saying that templates get rendered magically. What I am saying is that the time for rendering 1 Component linked to 14 CTs != time to render 1 Component linked to 1 CT * 14, and that the former seems to be performed quite efficiently.