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.
Item – Item save, deleted, renamed, etc.
Publish – Publish begin, complete, begin remote, etc.
Security – Login, Logout, etc.
User – Created, deleted, updated, etc.
Roles – Added, removed, etc.
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).
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.
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.
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.
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.
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.
This entry was posted in Events, Sitecore and tagged Events, Perfomance, Sitecore on October 3, 2014 by Alan Coates.