Pushing Sitecore to the limits and beyond

Category Archives: Events

A while ago, we at Pentia took over a massive Sitecore solution, which after 15 years of upgrades and development the maintenance cost consumed the entire digital budget of the customer.

In other words, the client was at a crossroad – to build new or renovate.

For this client the answer was relatively easy:

Firstly, the number of features and functionalities in the platform is vast, and just to scope and specify the entire platform was a massive, if not impossible, undertaking – and one which would claim a large number of resources internally and externally.

Secondly, while building a new platform (a massive task), the existing platform would have to be kept alive and slowly (painfully slowly) phased out over time. This means double resources for development, maintenance and operations.

Thirdly – and probably the most deterring factor – the change management involved in retraining the thousands of staff involved in and around the platform and across departments was substantial and disruptive to the entire organisation.

Therefore, a renovation project was established, and the first task was to reduce technical debt for the solution.

Reducing maintenance cost

One of the best ways to reduce technical debt is to reduce the code base, less code == less maintenance cost. In this case we managed to delete 28% of the code base, here are a few key figures for the solution when we took it over.

900+ sites (over ½ million items)

15 years old (multiple upgrades from Sitecore 4.x to 8.2 and single migration)

Custom Attributes

The point of this attribute is to clearly mark that a loosely referenced class, method or interface is indeed needed by the solution.

In other words, it indicates that a class, method or interface is used, even though it has no references. It’s possible to add a text to explain how and where it is used.

Obsolete

Whilst .net provides the Obsolete custom attribute; there are some missing options to indicate that the code is obsolete, and can be removed when a condition is met:

Specific date

Specific release is in production

3rd party system is updated to a specific version

The point of this attribute was therefore to allow us to plan the renovation project in stages and remove code when the referring parts were cleaned up.

Refactor

During this project we ran into many pieces of code, classes and structures which were in dire need of refactoring. But because of constraints in time, code not deployed, lack of knowledge, dependencies, multiple version of 3rd party system, or for some other reason it was not possible at that time.

Therefore, the best we could do was add this attribute and define why it should be refactored, and why it hasn’t been refactored.

The purpose of this attribute was therefore documentation and planning of the renovation process

Introducing a “Ensure Code Is Obsolete” Service

It is very difficult to ensure that code is obsolete and is never called and that is why it is so difficult to delete code.

What we needed was a somewhat conclusive measurement if the running code was being executed.

What we decided to do was to introduce code in the solution that collected data on code executed across all running solution instances and aggregated the data and presented the results, to ensure that the code was not required.

The IIncrementCountService interface was introduced to provide the ability to count how often the code is executed and then send the results to be aggregated with the other instances, by the content management server.

Implementation Challenges

The Content Management, Content Delivery, Utility & API instances are in different network zones without access to each other.

The implementation must have a minimum impact on performance, network traffic, database storage.

Not introduce any new databases and or tables.

As we do not have access to production environment apart from the Sitecore Client, it is not possible log the data the file system.

Sitecore Remote Events

Remote events (see this blog for a good introduction) provide the perfect mechanism to allow all instances to send their counter data to the Content Management service which is responsible for aggregating the data and presenting the results.

You must be careful with events as if you flood the event queue table it can kill the performance of ALL your sitecore instances.

The following configuration was introduced (see my blog post on Type Safe Settings) so the IncrementCount function will only raises an event when one of the following is true:

The count exceeds 1000

The threshold of 15 minutes is reached

A new day starts

This ensures that the event queue is not overloaded and will minimize performance impact, network & database usage.

The IncrementLocalCountService class is responsible for incrementing the count, caching it locally and raising the event to notify the Content Management server, when one of the afore mention threshold is met.

Who is responsible for aggregating the results?

The content Management is responsible for aggregating the results. It requires some extra configuration, to register that it will subscribe to handle remote events, raise the event and it then handle the remote event (see blog for more information).

Where is the Data Saved?

Ideally it should be saved in its own SQL database.

Unfortunately, we were not allowed to introduce and new databases and or tables, so we had to use the sitecore IDTable. The CounterRepository is responsible for retrieving, updating and persisting the counters in the IDTable.

Presenting the results

No magic here a simple counter.aspx pages, which reads from the CounterRepository and displays it in a table, with the option to clear the database. Also some code to ensure that only Sitecore administrators can access the page. See Part 2 in the series.

I was asked to investigate why the Sitecore client for a Foundry solution was so slow, I discovered that the performance was due to an error in the Friendly names shared source module, whist the fix was relatively simple I decided that it would be a good idea to share some tips whist working with Sitecore events.
But before we dive into the problem and the solution, I thought it would be good idea to give a brief introduction to events and how to react to them

Introduction to Events

In Sitecore it is possible to subscribe to events and in fact cast your own events. Sitecore events are defined in the web.config under the section /configuration/sitecore/events. The Sitecore API events are grouped into the following type of events:

Item – Item save, deleted, renamed, etc.

Publish – Publish begin, complete, begin remote, etc.

Security – Login, Logout, etc.

Template – updated

User – Created, deleted, updated, etc.

Roles – Added, removed, etc.

Database – property changed.

Id Table – added

Media events

How to subscribe for the item save event

In order to subscribe for item saving event you need to add your event handler to the event definition in the web.config, see below (note I removed all the the events for sake of clarity)

Then you have to implement the event handler which must accept a sender object and an event arguments object see below.

In order to get the item being saved, Sitecore provides a helper function to extract it from the event arguments (see above).

Raise Custom Events

It is possible to raise your own custom events, using the code below. Sitecore and a lot of modules raise their own events which are not defined in the web.config.

Event.RaiseEvent("myevent:happened", myObject, this);

Causing events within an event handler

Well let’s get back to the problem; the Friendly names module iterates over a number of items which defined rules i.e. what to string to find in the item name and what to replace it with.

The functionality is great as it allows the editors to create items with illegal characters, Danish characters etc. and they are replaced with a space and or the URL friendly version. Optionally the the display name updated with original name (with the illegal characters), when the item is saved (either after been created or after being renamed).

The problem came from the implementation where each time it iterated over a rule, EndEditing() was called twice, which in turn would cause an item:saving event to be cast.

Therefore each time an item was saved, it would generate over 100 save item events and therefore the Sitecore client started to run very slowly. If by mistake a rule had the same find and replace string the code would go into an infinite loop 😦

There are 2 solutions

Re-code the handler – so it iterates over all the rules and then checks if the name has changed, if so the name is updated (therefore if it contains one or more illegal characters only 1 additional saving event is cast)

Disable events from be cast using new EventDisabler()){}

I do not like solution 2, as it is possible that after the item name changes other event handlers should react to the event, therefore I would strongly advise you use approach 1 as an single additional event is acceptable as the item did change.

Performance of event handlers

Always consider performance as the code will be called a lot and will affect the performance of the solution and specifically the Sitecore client.

So please ensure that the code has as small a performance foot print as possible and exit the code as soon as possible, here is a list of common things to check before you actually react to the event.

Check template of item – In most cases you only want to react to an event from a specific type of item, therefore check if the item has that template if not exit.

Check the database – sometimes you only want to monitor events in specific database (i.e. save from the Sitecore client that affects the master database, therefore no need to react to save events for the web database)

Check if the item is a content item

Check if the item is a media item

Check if the user is an administrator

Check if the event affects an item

If the event handler takes a long time, consider starting a background task. In addition consider what to do if the code fails, therefore log as much as possible in the event of an error to help with debugging.

I hope this article helped as it has been my experience that 9 out of 10 performance issue are caused by slow code in pipelines or event handlers.