Real short post this one, but I have seen this a few times from different developers, so I am now considering that this is a common mistake and can be disastrous for performance.
The mistake is this – developers using code like the following:
@Html.Sitecore().Controller("ControllerName", "MethodName");
This code is fine and dandy IF you want to execute a controller with frills. HOWEVER, the number of times I have seen it used on the Layout to bring in Metadata, Header, Footer or any other statically bound rendering. This WILL BYPASS Sitecore’s output caching mechanisms altogether, so every page of your site (potentially) execute every controller added in this manner.
In the code below, I have simply created a controller rendering in Sitecore (though could be any) and used its ID to display the statically bound rendering using @Html.Sitecore.Rendering().
@Html.Sitecore().Rendering(RenderingConstants.MetaData, new { Cacheable=true, Cache_VaryByData=true })
Note also the EXPLICIT caching, at the time of this post, Sitecore still has an MVC based bug that means the rendering items caching settings are ignored altogether (there is a patch and I hope it will become core)
The RenderingConstants is a simple constants file which looks like this:
public class RenderingConstants { public static string MetaData { get { return "{640D2D99-D650-4DE9-9142-214F7AB65B04}"; } } }
Conclusion
In one instance I changed this, it resulted in a 6 fold increase in performance overall of the site with the mega-nav, header, footer, metadata & scripts being added in this manner.
Nice post. I have tried it and apparently { Cacheable=true, VaryByData=true } doesn’t work that well. When I use { Cacheable = true, Cache_VaryByData = true } as described at http://stackoverflow.com/questions/26050994/how-can-i-enable-caching-for-a-sitecore-controllerrendering it does work.
Ha ha, that’ll teach me for writing things off the top of my head – nice spot !! π I will amend
Cheers
Nat
Pingback: Statically add a Rendering to a layout – Andy Burns' Blog