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:

1. Item – Item save, deleted, renamed, etc.
2. Publish – Publish begin, complete, begin remote, etc.
3. Security – Login, Logout, etc.
4. Template – updated
5. User – Created, deleted, updated, etc.
6. Roles – Added, removed, etc.
7. Database – property changed.
8. Id Table – added
9. 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

1. 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)
2. 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.

1. 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.
2. 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)
3. Check if the item is a content item
4. Check if the item is a media item
5. Check if the user is an administrator
6. 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.