A key component of digital experience management is effective information retrieval. A simplified approach is required for websites, applications, and platforms containing a lot of material so that consumers can easily get the data they require. This need is met by Sitecore, a well-known name in the field of digital experience platforms (DXPs), which provides powerful and comprehensive search functionality. We will travel into the realm of Sitecore Search in this article, learning about its capabilities, architecture , and the enormous value it offers both developers and end users. Introduction to Sitecore Search A headless content discovery platform powered by AI , Sitecore Search enables you to build predictive and custom search experiences across various content sources. To extract and ...
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.
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.
: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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.0Go 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:
The patch config to disable the initialize pipeline:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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:
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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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 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.
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.
This article will provide the details about Sitecore GraphQL queries usage and how it will be useful in creating Sitecore projects especially Sitecore JSS projects. The topics covered under this Sitecore GraphQL article are: • Overview of Sitecore GraphQL (GQL) • Setup GraphQL (GQL) in Sitecore • Usage of Sitecore GraphQL (GQL) in Sitecore JSS • GraphQL (GQL) Queries Usage o Get an item by path and show field id and name o Return the name and value from all fields o Get the values of Treelist or Multilist field type o Get the template field details with values of current item o Get the field values using Aliases o Return a specific field with Alias ...
A SharePoint Feature is a functional component that can be activated and deactivate at various scopes throughout a SharePoint instances, such as at the farm, site collection, web, etc. Features have their own receiver architecture, which allow you to trap events such as when a feature is installing, uninstalling, activated, or deactivated. The element types that can be defined by a feature include menu commands, link commands, page templates, page instances, list definitions, list instances, event handlers, and workflows. The two files that are used to define a feature are the feature.xml and manifest file(elements.xml). The feature XML file defines the actual feature and will make SharePoint aware of the installed feature. The manifest file contains details about the feature such as functionality. The "Feature" is one of the major concepts in WSS3.0. The Feature is a container of various defined extensions for SharePoint. A Feature can include any number of files, but it mus...
Sitecore Experience Manager Cloud, or XM Cloud is a game-changing force in the field of digital experience management in the age of cloud computing. We must identify the fundamental components that make up this cutting-edge platform in order to fully appreciate its capabilities. Join us as we dissect the fundamental elements that make up the Sitecore Experience Manager Cloud (or XM Cloud) architecture and investigate how they work together to produce a dynamic, scalable, and customized digital experience environment. Sitecore XM Cloud Overview The SaaS enterprise-ready , cloud-native CMS from Sitecore called the Experience Manager Cloud (XM Cloud) allows for the creation of content only once and delivers it to every channel for exceptional client experiences. Developers and marketers can q...
