0 Comments

Developing with Sitecore and specifically deployments for me is similar to developing with SharePoint in the old days. You have to deploy a bunch of files to the server and IIS has to spin up again. Depending on the amount of processes, services and other stuff this can take a while. So when we want to debug our code and do a couple of deployments the amount of waiting time stacks up. I easily could open an extra tab in my browser and load up Netflix to watch a new episode of whatever series that's running at the moment.

And there the performance sinks in! Really! Haven't seen that before on Sitecore 8.x, but now in 9.01 the performance of spinning up Sitecore, getting to the log screen, the Content Editor and the Experience Editor. Also we've got SXA running. And no, I'll show later that performance on that is just fine.

Profiling the Web Application

Let's jump in right away with the log which I created with Ants Profiler:

What show immediately are the red lines on the right indicating something's taking a lot of time. Too much time: 46 seconds! And no managed code has been executed yet. Executing the managed code is fast and shows no sign of being sluggish. Then what could it be and what is this Rebus? I grabbed my bible called Google and searched for the keywords "sitecore rebus". Got some hits which pointed to EXM (Email Experience Manager for Sitecorer 9). Then I stumbled upon the following:

So Rebus is used by EXM to handle communication between CM's and CD's. As far as I can see it relies on SQL Server. And some magic is happening while spinning up the server.

The variables

Having a slow environment I tried to do what most developers would try:

  • do an IISRESET
  • reset SQL Server
  • reset Solr
  • disable some services which a not needed during development
  • full reset of my laptop
a full reset of my laptop gave me back the performance but after a while it got slow again

Solr indexes

A colleague of mine pointed out that Sitecore 9 highly depends on Solr indexes and working with the Experience Editor means the indexes should be in order otherwise you will get a big performance penalty. There are some ways you can trigger this reindexing:

  • Indexing Manager - From the Launch Pad go to the Control Panel and access the Indexing Manager. Here choose to select all indexes and click Rebuild
  • Content Manager - From the Content Manager you select the Developer tab and click the button 'Rebuild all'. This does the same but with less steps to take. We developers tend to be lazy ;-)

The effect of the indexing was great and gave me the feeling of a faster experience but within 1 day to a few weeks I had to do this over and over again. Still had the feeling this wasn't the solution. I thought to give it a few weeks, also being busy on several projects.

Turning on EXM

Thinking it was EXM's problem I opened my web.config and changed the following key which I set from yes to no:

<add key="exmEnabled:define" value="yes" />

This increased the performance of spinning up IIS with 30%!!!

Forcing Sitecore to go ludicrous speed

The show isn't over. This is a great way to gain some performance but when we need the EXM we cannot turn it off. So what next? Then I remembered from my earlier SharePoint projects that a huge gain you'll get by setting one variable in SQL Server:

By default when installing SQL Server it will set the property Max Degree of Parallelism to 0. But when you want SQL Server to use multi cores you need to set this value to 8 (amount of my virtual cores) and restart the service.

And now a summary of times measured with and without EXM enabled after setting the value to 1 including SXA installed (and no power cord attached to my laptop):

EXM onEXM offspinning up to login page40s17slogin page to Control Panel5s3sfrom Control Panel to Content Editor6s3sfrom Content Editor to Experience Editor16s13s

So, glad we fixed it :-)

Comments