In the previous Sitecore Performance Tuning article
Collect Sitecore Site Performance Data points I explain about how Sitecore OOTB tools like admin pages, configurations, etc. can be used to collect the data points which can be used as a starting point to concentrate on particular Sitecore related resources.
Sitecore Performance Tuning Article Series:
Sitecore 9 Performance Tuning
Sitecore Front-end Performance Tuning
Collect Sitecore Site Performance Data Points
Sitecore 9 Performance Tuning :: Sitecore box performance tuning points
In the continuation of Sitecore performance tuning, I will try to explain the ways which needs to be consider in Sitecore development for website. For this web to work on following items in Sitecore
Cache
Azure Portal Changes
Tuning Procedures — IIS Settings
Enable IIS HTTP keep-alive
Disable SPEAK Pre-compilation
Optimize Compilation
Content Editor Performance
Sitecore - Procedure to Disable WebDAV
Redis cache
Sitecore Support Patch# 223702
History Table
Cache: Go to top
Sitecore uses various caches to store data, rendered presentation logic and other information in memory in order to improve performance and response time. A cache is a dictionary that keeps track of when each entry is accessed. The data that is stored for each entry depends on the cache. How the cache is used also depends on the cache.
The details of different caches are: These are caches that inherit from Sitecore.Caching.CustomCache class. There are many more caches that are instances of Sitecore.Caching.Cache.
We can monitor the cache using Sitecore OOTB application pages http://[host]/sitecore/admin/cache.aspx.
There are many types of cache’s in Sitecore like Prefetch Cache, Data Cache, Item Cache, Html Cache/Web Cache/Output Cache (Rendering Cache).
For Data cache Configuration we can specify the maximum size of the data cache in the web.config. You can either alter the DefaultDataCacheSize setting:
< setting name = "Caching.DefaultDataCacheSize" value="10MB" />
Or you can set it per database in the /databases/database section:
< cacheSizes hint = "setting">
< data > 20MB</data>
< items > 10MB</items>
< paths > 500KB</paths>
< standardValues > 500KB</standardValues>
</ cacheSizes >
The HTML cache will be different depending on which item you are trying to access. Below describes the different vary by parameters:
• Vary by Data: Sitecore caches the output based on the item accessed. When the same item is accessed for the second time, the HTML will be loaded from the cache. Typically used for headers and footers.
• Vary by Device: Sitecore caches copies of the output for each Device being used. Recommended for adaptive designs.
• Vary by Login: Sitecore caches two copies of the output. One is for authenticated Extranet users and one is for unauthenticated Extranet users.
• Vary by Param: Sitecore caches the output for each parameter accepted by the rendering. Used in conjunction with rendering parameters.
• Vary by QueryString: Sitecore caches the output for each unique combination of query string parameters. Used with forms that have been embedded into the site.
• Vary by User: Sitecore caches the output for each authenticated user. Used with personalization enabled on websites.
Configuration: You can configure the allowed size of the HTML cache and whether it should be enabled or not for each of your sites. This is done in the sites section of the “<drive>\inetpub\wwwroot\website\web.config”. See the following line:
< site name = "website" virtualFolder="/" physicalFolder="/"rootPath="/sitecore/content " startItem="/Home"database="web" domain="extranet" cacheHtml="true" htmlCacheSize="10MB" enablePreview="true"enableWebEdit="true" enableDebugger="true"disableClientData="false" />
We need to update configuration files or need to add patch config for Cache related changes:
1. Prefetch cache: Sitecore has prefetch caches for each database it uses (Core, Master and Web). The configuration files it uses are located in \Website\App_Config\Prefetch.
Add Prefetch via Patch config:
Bigger Prefetch gives slow startup, but it can give you better performance while opening Content Editor or Page Editor because your items’ data are already fetched from Database to Prefetch Cache.
When to use prefetch
-You should use prefetch in the Homepage, for example, as it is the most frequently visited page.
-You should prefetch Home item and its immediate children.
Also, a News pages should be prefetched as it is supposedly visited frequently. You should prefetch “News Template” and their children, for example.
For better Prefetch cache, you have to find out three things:
- Which are the pages used the most in your site like Homepage.
- Which are the pages, whose children are accessed frequently.
- Which kind of pages(templates) are used the most.
• <cachesize>300MB</cachesize>: describes Sitecore will do prefetch upto 300MB.
• <template desc="mytemplate">{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}</template>: Defines that items of the specified template will be prefetched.
• <item desc="myitem">{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX }</item>
:Defines that the specified item will be prefetched.
• <children desc="childitems">{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}</children>:Defines that specified children of the given item will be prefetched.
• <childlimit>100</childlimit>:Defines a limit to the number of children to include in the prefetch cache.
Remove Prefetch via Patch config:
Bigger Prefetch gives slow startup, but it can give you better performance while opening Content Editor
If you already tried increasing DTU's on databases or upscaling the server to B3 in Sitecore Azure PaaS and still facing, slowness in first load of pages in the sitecore backend (login, desktop, experience editor, content editor).
In the above cases, we have check the Prefetch cache settings for following keys in the environment using [WebRoot]/sitecore/admin/cache.aspx: verify its cache limit
• SqlDataProvider - Prefetch data (core)
• SqlDataProvider - Prefetch data (master)
To improve the performance, we can remove these prefetch caches by using the patch provided by the Sitecore support team (https://kb.sitecore.net/articles/290593): deploy this patch file
The Sitecore Experience Platform cache's prefetch functionality attempts to pre-populate item caches on role start up. This causes excessive SQL Server DTU consumption on the core database, SQL timeout exceptions, and unresponsive websites. In some cases, for example on topologies with 4 Sitecore roles and small SQL Server tiers, the DTU on the core database can reach 100% and remain there for up to 40 minutes.
https://sitecore.stackexchange.com/questions/12183/how-can-i-improve-startup-times-content-management-in-azure-paas
https://kb.sitecore.net/articles/290593
2. Set Initial Cache Values:
In this task we will learn how to sets the initial values for the Sitecore Database and html output Caches, depending on the environment. These values are used during the tuning phase of the caches and find below sample cache values:
CM instance configuration files:
For Core DB:
For Master DB:
CD instance configuration files:
For Web DB:
Tuning of Initial Sitecore Cache:
This task describe the procedures used to tune the Sitecore prefetch, data, and item caches, using a load generator and the Sitecore cache.aspx page to monitor the size and eviction of the various caches.
Cache tuning is an ongoing process that needs to be revisited from time to time.
1. While the load generator is running, navigate to /sitecore/admin/cache.aspx page. The caches of interest, depending on environment, are the Master[data], Master[items], Web[data], Web[items], SqlDataProvider- Prefetch data(master), and SqlDataProvider - Prefetch data(web).
2. If the
Delta for the cache fluctuates constantly, or if the
size of the cache is consistently > 80% of the
MaxSize, increase the size of the caches by 50%.
3. If the size of the
cache remains < 50% of the MaxSize, decrease the
size of the cache by 25% to reduce memory consumption.
We can work on following items in Azure Portal to improve the performance of Sitecore instance:
1. Deploy Resources to Premium(P) v2
2. Sql servers to better Database Thermal Unit (DTU)
3. Move all db's to elastic pool
Tuning Procedures – IIS Settings contains a series of tasks designed to check the configuration of the IIS web server. Proper configuration of IIS helps the Sitecore implementation run at its peak performance .
Enabling the HTTP keep-alive reduces the number of connections required to be opened. If the HTTP keep-alive is disabled, a new connection is made for every requested object on a web page.
Disable SPEAK Pre-compilation: For Sitecore Instance < 8.0 Go to top
While tools are important, SPEAK pre-compilation may be the most important issue. In general, the default Sitecore configuration supports developers, and mainly needs alteration for security, scalability, and otherwise in production environments. One exception may be SPEAK. By default, Sitecore precompiles SPEAK applications at each application initialization. This can improve performance for users in the production content management environment, but presents unnecessary overhead in content delivery environments, and especially for developers who need to restart ASP.NET frequently due to compilation, configuration changes, package installations, or otherwise.
• We can also disable initialization of pipeline processor which responsible for precompilation with Patch config file:
Sitecore 9 Configuration file present at: [WebRoot]\App_Config\Sitecore\SPEAK\Sitecore.Speak.config
The patch config to disable the initialize pipeline:
Optimize Compilation: Go to top
The Sitecore will compile unchanged .cshtml SPEAK views every time, when application compiles.
Sitecore depends on a WHOLE LOT of dynamically compiled SPEAK renderings. When you start it up the first time, ASP.NET compiles them and stores them in its compilation cache. As long as you don’t change any dependencies - e.g. dlls, global.asax - .NET can update the cache selectively when the cshtml file is changed, and it’s fast. But as soon as a dependency is changed - e.g. your site dll - .NET throws out the whole site’s cache and compiles it all again, just to be safe. With Sitecore it takes lots of time.
You can instruct .NET to ignore dependency changes and only recompile dynamically compiled files when the file itself is modified. This has some potential dangers if you modify a dependency without changing the dynamically compiled file and make a breaking change;
see the MSDN article for details of the things to be aware of if you enable optimization.
Basically, it takes a less strict approach to compilation, and doesn’t necessarily compile every little item when you compile.
To prevent precompilation, you can set the optimizeCompilations attribute of the /configuration/system.web/compilation element in the /web.config file to true. Because this element is not within the /configuration/sitecore element, you cannot use a Web.config config include file to implement this change. We can enable it in
[WebRoot]\Web.config:
<compilation defaultLanguage="c#" … optimizeCompilations="true">
Content Editor Performance: Go to top
A couple of other things you can do to help with Content Editor Performance are to:
1. Disable Rendering of all items in the tree on initial load. This will mean a slower load when browsing lower levels of the tree but should make the initial page load quicker when browsing around content editor:
<setting name="ContentEditor.RenderCollapsedSections">
<patch:attribute name="value">false</patch:attribute>
</setting>
2. Turn off Security checking on tree nodes. This has one downside that means content editors will see parent items in the tree they shouldn't see and get a error message saying they don't have access if they click on it.
<setting name="ContentEditor.CheckSecurityOnTreeNodes">
<patch:attribute name="value">false</patch:attribute>
</setting>
3. Turn off Checking for children on tree nodes. This has one downside that means content editors will see an arrow for child items in the tree (even if there are no child items) then if they click on it it will disappear.
<setting name="ContentEditor.CheckHasChildrenOnTreeNodes">
<patch:attribute name="value">false</patch:attribute>
</setting>
Patch Config in CM: [WebRoot]\App_Config\Include\zz\zz.SC.ContentEditor.Performance.config
Sitecore - Procedure to Disable WebDAV: Go to top
WebDAV allows users of Web clients such as browsers to manage files on Web servers using Web protocols such as HTTP or HTTPS. With WebDAV, users can drag-and-drop files between the Windows desktop and the browser.
Disabling WebDAV on the content delivery server(s) makes sense as it is not expected to be used in these environments.
To disable WebDAV:
1. Open the web.config file in an editor — located in the web root directory.
2. Search for WebDav and comment all attributes:
3. Save your changes.
4. Go to [WebRoot]App_Config\Sitecore\CMS.Core\Sitecore.WebDAV.config and disable it like [WebRoot]App_Config\Sitecore\CMS.Core\Sitecore.WebDAV.config.disabled or delete it after taking the backup.
Sitecore Recommendation:
Sitecore recommends disabling WebDAV on the production content delivery servers to reduce the number of log files being created. Also, Sitecore recommends disabling WebDAV on the content management servers if the WebDAV functionality is not being used.
Sitecore SXA: Go to top
Please check article for more details
https://doc.sitecore.com/developers/sxa/18/sitecore-experience-accelerator/en/set-sxa-caching-options.html
Redis cache: Go to top
Use redis cache to improve the published site performance (CD) and for this shared session needs to be enabled in the Scaled environment.
Please check articles:
Scaling and configuring session state
Configure a shared session state database using Redis
Sitecore Support Patch# 223702: Go to top
Cord DB > Properties Table
Sitecore create a ticket for each user when login onto the CMS. This ticket entry is stored in the Properties table of the Core database. Login into the CMS may become slow with time and also based on the number of users accessing the CMS. This is because of the large number of ticket records being stored in the Properties table. There is currently an agent which performs the cleanup. However, the agent is not so efficient. Due to large amount of records in Properties table, some users will receive a timeout message.
Fig: Sitecore > Core DB > Properties Table Records before patch deployment
The Sitecore support released the patch for "SC_TICKET entries are never cleared from Properties table." (
#223702) and needs to be deployed on CM instance. This issue is fixed in Sitecore 9.1.
This patch contains a config file and an assembly.
Note: After deployment of patch restart the app service/ application pool recyle (IaaS).
After Patch deployment Core DB > Properties table records:
Fig: Sitecore > Core DB > Properties Table Records after patch deployment
Logs: After patch deployment
2019-06-03T02:50:28 PID[10392] Information ManagedPoolThread #7 02:50:28 INFO Job started: Sitecore.Support.Tasks.CleanupAuthenticationTicketsAgent
2019-06-03T02:50:28 PID[10392] Information ManagedPoolThread #7 02:50:28 INFO CleanupAuthenticationTicketsAgent: Total number of authentication tickets to process: 104
2019-06-03T02:50:28 PID[10392] Information ManagedPoolThread #7 02:50:28 INFO CleanupAuthenticationTicketsAgent: Number of expired authentication tickets that have been removed: 0
2019-06-03T02:50:28 PID[10392] Information ManagedPoolThread #7 02:50:28 INFO Job ended: Sitecore.Support.Tasks.CleanupAuthenticationTicketsAgent (units processed: )
Run below queries when:
• Slow performance during publishing.
• Slow performance during indexing.
Run the following query, replacing /* database name */ with the name of the database that the script runs against
USE /* database name */
/* TRUNCATE History TABLE */
IF OBJECT_ID('History', 'U') IS NOT NULL
IF((SELECT COUNT(*) FROM [History]) > 1000)
BEGIN
TRUNCATE TABLE [History];
PRINT 'Truncated the History Table';
END
Sitecore recommends that the number of rows (entries) in the History table be less than 1000. This prevents timeouts from occurring while the cleanup agents run.
Credits/References:
Its my sincere apologies, If i missed the article name to provide the credit to my fellow Sitecore Community Contributors. For this, please DM me to include the credits.
