It feels like a long time ago when we first started this series and it has been a fantastic journey thus far. This series has really taken me back to basics in considering the decisions we make on Sitecore projects and what the medium to long term impact of those decisions is.
I thought therefore I would cover a real-life use case of an issue that incorporates some of these posts and show what advantages they have given me and on occasion, why it is that I would have cornered myself had a chosen another route. The project in question has taken a few experienced developers around 11 months to develop and has grown semi-organically based on the requirements from the users.
I would prefix this post with saying – no solution is perfect, neither ours nor any other solution I have seen thus far in my development career. As you will see, myself and the wider team have made mistakes along the way, but it has been the ability to change those decisions that has been key.
During the current project – I, an experienced developer of 15 years who is well used to TDD and follow SOLID principles wherever possible, am unafraid to admit that I definitely broke the build at least 10 times – some of this was down to missing code in my commit, but certainly some of it was me breaking unit tests that I wasn’t working on (oops!). Further to this – I actually, were it not for running the unit tests regularly (NCrunch is on the ‘to buy’ list), would have probably broke the build closer to 50 times during the development cycle. This would not only have wasted my time (in fixing it), but my colleagues time in being blocked on their work whilst I fixed it.
If each one of those breaks cost an average of only a single man hour between all of the developers within our team (which I believe is well under), that’s 10 man hours lost. If each developer in our team did similar (and bear in mind, as with all teams, there are differences in familiarity etc) that is 30 man hours potentially lost. That’s nearly a week… Some of those fixes in reality were of course – tick the missing files.
Now take that scenario into the ‘commit and run’ or a wide band refactor. The ability to understand what you broke and how is key, and without the unit tests, other than code compiling – you can never be certain of how your code behaves.
Extend this into the idea that we had no unit tests at all. Any / all of these bugs would have made it into the development, potentially been missed, built upon. It could potentially be so much worse.
As you may / may not have seen, I have been heavily pushing to optimise the performance of our current implementation.
So, starting with a bit of history. Despite our new Sitecore solution significantly outperforming it’s predecessor (about 25x quicker), it still unfortunately didn’t meet the peak traffic levels required by my client. This is unfortunately a quarterly occasion and was shortly after the site went live. During this period, the site traffic increases by approximately 600% – 700% of it’s regular traffic levels which are usually reasonable. Now, again, this traffic peak also unfortunately happens over a very short period – less than one hour in fact. We had tested for this during UAT, and unfortunately for a number of reasons, our tests had not accurately reflected the traffic increase we were expecting. As a result, the Site did stop functioning for around 2 minutes during this peak time (red faced and much to my disappointment). This of course lead to all of the usual post event analysis on what went wrong, where our tests were flawed and so on. Off I went on my part of the investigation – and so it goes….
This process involved a real bottom up look at the performance of the following:
- ‘Vanilla’ Sitecore
- Our own code
The investigation of the ‘vanilla’ Sitecore performance lead to these posts on Strategies to optimise Sitecore MVC Performance
and Further strategies to optimise Sitecore MVC Performance. These in themselves are actually a great example of why we shouldn’t fight the framework as it eventually lead to support tickets that on initial investigation significantly improve the raw performance of Sitecore’s MVC implementation, which is still on-going and proving very fruitful. Had we gone in a non-standard direction with our overall implementation, we would have found it near impossible to simulate the setup of our thousands of lines of code and unable therefore to show Sitecore the issues we had been suffering leaving me and the team fairly isolated.
It’s no surprise that our solution uses Glass Mapper, so turning my attention to this. I worked closely with the vendor’s and, as a result, we successfully improved the speed of it’s mapping process by approximately 33%. For those who are interested, please contact Glass for more information and figures. Again though, had I chosen to use Glass in a non-standard way, I would have found it very difficult to describe the issues, and even harder to actually perform the necessary upgrade in order to utilise the fruit of our labour. So, a quick upgrade or two later and we were able to adopt.
Our Own Code
Finally – our own code. Now on this front – I definitely found a few smaller errors, one in particular in the way developers had chosen to use Glass revolving around the Delegate mapping which I will cover soon lead to a significant performance recovery (non-lazy loaded fields to be precise).
We also then following on from the performance analysis of Sitecore, found alternative ways to cache the pages leading to another significant performance improvement.
This in combination has achieved the following:
- Helped diagnose our issue’s and report them effectively to Sitecore support.
- Helped to contribute effectively to an open source solution that I very much value.
- Proved to the wider business that Sitecore can in fact achieve the traffic levels they desire.
- Proved that as developers we can achieve a flexible solution that has grown with business need.
- Took away the words ‘Sitecore can’t’ – a personal annoyance that I have found all to often should actually described as ‘I / we don’t know how to’
This was all however made possible or at least infinitely easier by not fighting the framework, by embracing our choice of platform rather than trying to write our own crazy solution. Had we followed a crazy model as described in The Series Introduction, I would have never been able to manipulate a few settings in Sitecore
We are using Glass in a (near) standard way. We are following best practice as shown by the review of our Site undertaken by Sitecore themselves. Sure – we still have a few things to sort out, but I have never implemented any solution in my life and said wholly ‘There is nothing I can improve upon.’, if I did, I might actually quit my job.
With this development, at this stage we actually didn’t and don’t know as developers which renderings they will be personalising, we have assumed that pretty much any them can be. Following much of what was written on Sitecore Presentation. In this case, that is standard practice, but how else did it prevent us cornering ourselves ?
First of all, as stated above, we don’t know what the DMS use will actually be going forward, but we do know it will be used. This meant we could quickly decide NOT to use rendering parameters for a number of the settings within the solution, and as a consequence, much of the settings that would have been there were instead put onto settings items with standard values and all the other goodness. There are still of course rendering parameters in use, but on a much more limited scale than earlier projects I did in Sitecore.
Secondly, we are actually using a couple of other features within Sitecore that are not directly DMS, but rather relate to the restriction of how content is displayed. As a consequence we are actually performing Layout Switching for ‘restricted’ users and also personalisation based upon user’s security status (which is controlled from an external SSO & authentication process).
The final justification for its use is actually quite strange, but it was born out of the performance problems we were experiencing above with caching, but as I discovered some of the issues we were suffering on the performance side were related to how we had set our caching options, I used a mixture of changing where these were set, and changing some of the data source items to manipulate Sitecore into a different design.
These changes would definitely not have been possible had I used a crazy framework as described in the introduction to this series, and was in fact one of the key drivers to not only the performance issues the client had suffered with their previous solution, the reason for the first post in this series but also one of the key focuses of the client and a good number of people within the business with the classic ‘Sitecore can’t’ opinion.