Jeremy Davis
Sitecore, C# and web development
I read a blog post earlier this week that talked about the benefits of compiling your View files to increase performance in Sitecore applications. Reading that post (which
I stupidly failed to keep track of the link to, so can't reference it now
the comments pointed me back to) reminded me of an interesting issue that came up on a project I was looking at recently. If you're interested in the raw performance of your Sitecore sites, you might want to consider this as well when you're planning your views:
A few weeks back I wrote about spotting site performance challenges in the patterns you might see in trace data. But over the years I've noticed another set of repeating patterns that can be relevant here: Those of how a development team can find itself thinking and acting in the run up to a project hitting problems.
If any of these resonate with you and your team, maybe it's time to take a step back and think about how you can improve things?
Sitecore's config patch files are great. But sadly it's entirely possible to cause yourself headaches with them. I've written before about how it's possible that small typos can cause big issues. In that style, a colleage brought an issue to me recently which was an interesting new variation on this fun...
I find myself doing quite a lot of work on performance for Sitecore websites at the moment. Whenever I do a similar job for a group of clients, I start to spot patterns in the sites I'm working on – and it struck me that there are some common performance issues that can be spotted just from the overview graphs you see when you collect trace data.
So to try and help you all improve the sites you ship, here are three that I've come across in a few projects recently:
It's a pretty common requirement that deploying instances of Sitecore will require slightly different configuration on different servers. Different roles, like content management and content deployment, will require different settings and features to work. So it's not surprising that there are a variety of approaches to how you manage this configuration in your projects.
In the past I've often made use of separate config files, where you have a file for "config changes needed on all servers" and then further files for "config changes needed for CM servers", and even down to the level of "config changes needed on server CD01" if necessary. This works fine if your deployment process understands which files should go on which servers.
Recently, however, Sitecore have started to offer a "role based configuration" approach in the configuration of v9 – so you can deploy a single config file and the server can pick and choose sections of its configuration based on what role it is performing. But back in the real world, most of us are still supporting V8 (and older) sites, so is it possible for them to adopt something similar to this idea? Here's one approach that achieves something similar:
My first time having to configure Solr for Sitecore recently taught me a variety of new things. (I know – how have I managed to avoid it this long?) Most of the basics of the setup have been well documented elsewhere, so I won't repeat any of that. However setting up the site to use the Ninject DI container wasn't as smooth as the documentation suggested, so here are some notes on the issues I hit in case you find yourself stuck:
There's been a bit of a theme in my recent posts about scripting stuff, and that continues this week. I've been looking at some ideas for automating tasks for developers recently, and one of the things I was interested in was being able to get stuff downloaded from dev.sitecore.net without having to do it manually. So, here's some PowerShell that can help you with that...
I've spent the last week or so working on the config changes necessary to migrate a client site running Sitecore v8.1 from using Lucene to Solr for its search infrastructure. I've not worked much with Solr before, so this has been a good opportunity for me to learn about how it works and how it gets configured. But when I deployed my changes from my local development environment to a central testing server I discovered some odd behavior which Google didn't help with. So, for the good of search indexes everywhere, here's what happened...
I got the chance to speak at the Manchester Sitecore user group recently, introducing some tools and tricks that can be used to measure site performance while you're developing your Sitecore code. For anyone who wasn't there (and those who were but, want to refer back to what I said) here's a summary of the important bits of content from that talk...
Recently I've spent some time debugging some issues with a client site. One problem that came up during this work (which, sadly wasn't actually the problem I was looking for) was a set of errors from SQL Replication appearing in the Sitecore logs. In keeping with my previous ranting about keeping your Sitecore logs as error free as possible I spent some time working out how to solve this.
Since I'd not looked at databases at this sort of level for some considerable time, I'm writing down some notes for my future self, next time I have to worry about this sort of thing...
