Steps to improve performance - mitikov/KeepSitecoreSimple GitHub Wiki

Remove WebActivatorEx assembly

WebActivatorEx was used by SPEAK to power startup code execution.

The price to pay is loading/inspecting the whole bin folder.

The Sitecore-way of executing code upon startup is initialize pipeline, and that what is done now:

Remove assemblies for non-used technologies

Yes, assembly load time is minor. Do you want to be taxed a small amount each time, or prefer not to?

~300 minor timings together end up in a noticeable delay:

Compare timings Sitecore 7.2 (72 assemblies) vs 9.0 (338 assemblies):

If you do not use SOLR, MongoDB session state, why to keep the assemblies in the 'bin' folder?

Let database read data faster

Sitecore system items (core database) are expected have read workload - ratio of system update operations is miserable.

Sitecore reads item data by ItemID, thus introducing primary key for ItemID in core database will simplify its task = faster executions:

The query capable of adding clustered indexes:

CREATE UNIQUE CLUSTERED INDEX IX_ItemsID on Items(ID)

CREATE CLUSTERED INDEX IX_SharedFields_ItemID on SharedFields(ItemID)

CREATE CLUSTERED INDEX IX_UnversionedFields_ItemID on UnversionedFields(ItemID)

CREATE CLUSTERED INDEX IX_VersionedFields_ItemID on VersionedFields(ItemID)

Read less data

Sitecore has the concept of system items that are to be used for every request processing, examples:

  • Devices
  • Layouts
  • Templates
  • Home

In order to prevent concurrent SQL requests, we'll execute them as 'initial' prefetch.

The list of items is defined in App_Config\Prefetch folder - reducing the count of entries impacts the initial prefetch speed = startup performance.

Operate with less data

Every Sitecore item has a few system fields:

  • created/created by
  • updated/updated by
  • revision
  • owner

Over 95% versionedFields in core database belong to system technical debt query :

Leaving only one versioned field (f.e. created time) will allow indicate item versions exist.

ASP.NET Compilations

ASP.NET defines basic compilation settings as:

  • OptimizeCompilations - well explained here and here
  • Batch - compile a batch of pages instead of one link - pay more once vs pay less multiple times

NGen?

While JIT gives a flexibility of moving code between platforms, it still needs to be converted into machine commands specific to the end machine:

Should we have admin access, NGen largest assemblies will be beneficial for us:

Sitecore configurations

A) Do we need xslWatcher/media upload watchers locally? no = remove from web.config

B) Do we use ExM? no -> disable it by 'exmEnabled:define' in web.config. It is quite costly as brings Rebus with own threadpool & constant CPU pressure =\

C) Do we need diagnostic data? No = modify settings:

  • name="Counters.Enabled" value="false"
  • name="Statistics.CollectRenderingData" value="false"

D) Do we need diagnostics? No = remove any processor having 'Diagnostics' in its name:

  • processor type="Sitecore.Pipelines.HttpRequest.BeginDiagnostics, Sitecore.Kernel"
  • processor type="Sitecore.Pipelines.HttpRequest.EndDiagnostics, Sitecore.Kernel"
  • hook type="Sitecore.Diagnostics.HealthMonitorHook, Sitecore.Kernel"
  • hook type="Sitecore.Diagnostics.MemoryMonitorHook, Sitecore.Kernel"
  • processor type="Sitecore.Pipelines.Loader.ShowVersion, Sitecore.Kernel"

Summary

The system performance is proportional to the number of operations it must complete.

Less work = faster;

More computing power = faster;

Local improvements

  • Image load 57.4 sec -> 26.7 sec (!)
  • Total MSec JIT compiling : 13,2 -> 2,363 sec (!)
  • Home page load -> ~25 sec for 'cold' start
  • No csc recorded

We are only getting started.