Don’t Fight The Framework – Further strategies to optimise Sitecore MVC Performance.

Following on from Strategies to optimise Sitecore MVC Performance. I thought I would write an update to continue and show where I have got to with my quest to optimise the performance of our Sitecore MVC implementation.

Since my previous post, Sitecore have acknowledged some of my findings, and provided a couple of potential fixes for us to try out. On first investigation – these look promising (though my tests are ongoing). I also started to consider alternative methods of setting up parameters, data sources, caching following on from my findings.

So – in the last post I explored strategies to maximise the raw performance of Sitecore MVC, this involved:

  • Analyzing and presenting findings to Sitecore of potential hotspots in the MVC process
  • Using View Renderings Over Controller Renderings
  • Considering the use of model’s due to their performance impact.
  • Using static renderings where possible to reduce the overhead in the pipeline.

During this process, I found something a little interesting:

Quite often I have set up my parameters on the rendering item itself (under layout), simple things like a data source, default parameters, caching settings etc. I know that I am also not alone in this method as many a developer that I have worked with from here in the UK and from Denmark have done similar. It did get me thinking – since some of the performance issues that I have addressed with the Sitecore support team have been around slightly excessive calls to the rendering item parameters object (which requires it to parse the xml from the appropriate field and present it back as an object in the API), what would happen if I changed my settings in Sitecore? Would it allow for greater performance if I set the caching say on the standard values object or the content item itself.

The short answer to this was YES 😀 In tests – I found that by setting the caching settings on the standard values for the item and not allowing them to drop to the rendering item, it did actually improve performance quite a bit ESPECIALLY without the patch that Sitecore have provided. It did mean though that I also had to set my data source on the standard values or item though as it no longer appeared to read it from the rendering item. As yet – I am not really sure whether I got lucky before with performance issues and have missed this? whether the caching setting work at all from there (though they always appeared to in previous tests, and still do make SOME difference in the tests I have tried)? Whether it was previously an unexpected behaviour? Whether the behaviour has changed in later versions of Sitecore ? Or even – is this a symptom MVC in Sitecore ?

Determining Models From Views

I covered this since I wanted to try and see if I could alleviate the performance penalty from using the GetModel pipeline.

During this process I have also tried to implement an idea supported in Sitecore John’s post on Determining models from views. This is an awesome idea, and one I really think Sitecore should adopt more fully in time. This unfortunately – whilst very cool, actually performed the same or very slightly worse than Sitecore’s original code using the rest of the GetModel pipeline.

Conclusion

In this case – I am kinda just reporting it as I find it – wish I could say more than that! I would love to hear more on what others are finding with their MVC implementation’s under stress, what other strategies have you tried / succeeded / failed with?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s