In recent months I have been very busy working on the performance of Sitecore installations, this has included things like:
- Optimisations to the MVC pipelines – working closely with Sitecore support to improve some of the issues we found – shown in my posts on Strategies to optimise Sitecore MVC performance and Further strategies to optimise Sitecore MVC performance.
- Optimisations in Glass Mapper to achieve rendering times on par and even sometimes quicker than native Sitecore (this is amazing in itself!)
- Optimisations to our own code to help achieve the maximum performance out of it.
Traditionally it has been my opinion that (unless you use Ninject), the IoC container you choose would have little impact to your final solution. In traditional .net solutions, this TENDS to be the case; Indeed when using Sitecore with webforms, the impact TENDS to be less important, which means you are free to choose the IoC container based upon the feature set it provides (on webforms, property injection is a major nice to have for example).
During my Sitecore journey, my improving knowledge of Sitecore led me to better solutions around making the most of my IoC containers. This has led to things like resolve your Sitecore controllers from your IoC container, resolving configuration entries (pipeline) from your IoC container. I utilise these to great effect with Sitecore’s pipelines in particular, bringing various entries in using my container.
This has of course increased the level which the IoC container is relied upon, and in particular if you are using these techniques in the mvc.getModel, mvc.renderRendering or httpRequestBegin, this can easily result in a lot of leverage on your container.
These changes however, led me to revisiting the impact of my container of choice when using Sitecore solutions, and led me in particular to look at IoC container performance in isolation along with Daniel Palme’s great blog post on IoC container benchmarks and features.
Very quickly I realised that my somewhat lazy choice of Castle Windsor (as it ships with Glass Mapper) might actually be hindering the performance of our Site, so – as an experiment, I swapped it out (leaving just Glass running on Castle Windsor) for SimpleInjector. The result – a 4000 request / minute improvement in speed (local development machine)!
I love the fact that every day is a school day in our job, and that it allows us to strive for the (unattainable) solution perfection. This is a great example of where my traditional .net development experience both helped and hindered my efforts in Sitecore. I believe to become a good developer, you have to be unafraid to be wrong – certainly on this occasion I was (and one day I may even become a good developer 😉 ) 😀
So, especially in your Sitecore MVC solutions, there are a few key area’s to look at when it comes to solution performance, one of these should definitely be your choice of IoC container.