Recommended Practises, Search

Why does my Sitecore website perform so badly?

After many years of doing a lot of reviews on Sitecore I would conclude that it more or less always comes down to one single thing when pages perform badly: bad code. And when I mean bad code, I mean code iterating an excessive amount of items.

Iterating A LOT of items

Previously we used to see a lot of calls to descendants when solutions were using axis, xpath or Sitecore Query, but luckily this is a disappearing trend with the introduction of Sitecore Search in Sitecore 7. This does not mean that there are less bad code – maybe even on the contrary. The use of ORM and abstractions in many solutions means that layers of code can easily hide item iterations. Neither of the two patterns or technologies are inherently bad, but they do provide means to hide “bad code”.

The ARGH! Example

The example in the diagram below is from a customer here in Australia which had a problem with a very slow running product search. The diagram breaks down the different parts of the search page and describes the functionality and number of items hit by each part. It was part of the presentation to the client to highlight where the performance bottleneck was (and that Sitecore itself was not cause of the problem).

After looking through layers and layers of code (3000+ lines to be more specific), we discovered that the code in the different layers were searching Lucene and iterating search results, loading the items individually and recursively running business logic.

A simple search resulting in a page of 50 links would easily take up to 5 minutes, simply because the code was iterating in excess of 1.7 mio items from the Sitecore database –  which would take time in any solution 🙂

Excessive Item Iterations

To cut the very long story short: always keep an eye on number of items being iterated – and never rely on caching to do the trick.

Standard
Recommended Practises, Sitecore

How do I get the Publishing date for a page in Sitecore CMS?

During the last week I’ve stumbled upon this question multiple times (strangely enough when dealing with many Sitecore solutions I find myself stumble upon the same issues – and oddly enough, the same issue often arises on different solutions at the same time) and the answer is: “You need to determine what you mean by Publishing Date”.

Getting the date the item was published.

So you mean the date and time the page was transferred from the master database to the web database? Would this be the very first time the page item is transferred to the web database? Or maybe the first time the latest version of the page is transferred? Or maybe the last time the version was transferred?

The answer to all the above would be: There is no such date available in the Sitecore CMS API!

If you still want to pursue this path, John West has a brilliant post apparently solving this: http://www.sitecore.net/Learn/Blogs/Technical-Blogs/John-West-Sitecore-Blog/Posts/2011/08/Intercept-Item-Publishing-with-the-Sitecore-ASPNET-CMS.aspx

But you have to keep a couple of things in mind:

  1. Perhaps most important – does this date really make sense? Remember that this is not the date the page item was last changed, but merely the time of the transfer to the web database.
  2. This date would be the publish of the latest version to the web database.
  3. A full publish of an item would update this date – even if the item already exists in the web database. A full publish removes the items from the web database before a new publish commences.
  4. I am always most reluctant to make changes directly in the web database (as suggested by John West). There are generally many components of Sitecore (indexing, publishing etc.) which are based on items being transferred as-is from master to web. You might get it to work – but will every feature of Sitecore keep working? Correctly?

Getting the date the page was last changed.

Well this one is easy: Item.Statistics.Updated will give you just this, the date/time for the last change – any change – on the version of the item. By setting up workflows and a scheduled publishing strategy (which I would recommend on any solution) will transfer the page changes automatically to the web database, thereby getting an updated item published as soon as possible.

But! If you determine to use this field, keep in mind:

  1. The Updated date/time field will be updated by any change, e.g. both major revisions and just smaller changes. Even fields which are not shown on the page or not edited manually by users will trigger a change. For example: If an editor makes a revision to the text on a page on July 1., but an approver waits two months before approving the change (without content changes), the Updated date will be September 1. (because the item workflow state was changed on this date).
  2. There is no way for the editor to control this field (unless you start meddling with the inner working of Sitecore, which is never recommended). The field is controlled by Sitecore.

Using your own date/time field

Most likely, when thinking this issue through, you will arrive at the conclusion that the editors – or at least the administrators – needs to have total control over the Published Date shown on the page. This of course means that the field will have to be a custom field added to all page items – and the most straight forward solution is to just make the editors set the value when they make a change.

But if you need to automate the date/time value, there are a number of options which springs to mind:

  1. First option is to set the field value when the item is created. This can be done by setting the standard values on the template: http://briancaos.wordpress.com/2011/03/24/initial-field-values-for-sitecore-setting-a-default-future-date/
  2. You could change the date/time if some predetermined fields changes (e.g. the content fields shown on the page). This would be done in an event handler for the item saved event: http://www.sitecore.net/Learn/Blogs/Technical-Blogs/John-West-Sitecore-Blog/Posts/2010/11/Intercepting-Item-Updates-with-Sitecore.aspx
  3. You could update the field in a workflow action, e.g. approval. This would be require a custom workflow action. See more here: http://sdn.sitecore.net/upload/sitecore6/workflowreference-usletter.pdf

Things to keep in mind

  • Think carefully what you mean by “Published Date”
  • There are no “Publishing Date” concept in Sitecore.
  • Use the Updated date with care – it will get changed by Sitecore at every change to the item
  • Consider using a custom field for this. There are ways of automating the value in the field without meddling with the inner workings of Sitecore.
Standard