Monday, March 30, 2020

Sitecore Error Troubleshooting: Node.js error while setting Sitecore JSS Integrated Mode



Sitecore Error Troubleshooting: Node.js error while setting Sitecore JSS Integrated Mode

Problem Statement:

I was setting up the new machine with Sitecore Experience Platform 9.3 Initial Release and was successfully able to setup. After that I tried creating the Sitecore JSS Sample App and successfully able to use the sample app in Disconnected Application mode.

 Error-1: 
Once I tried deploying sample app into Sitecore using Integrated Mode and tried accessing the sample in Sitecore Experience Editor and I started getting following error:

As a prerequisite of Sitecore JSS I already installed the Node.js latest version and it was running successfully, and did the verification of following items:
  •  Checked the Node.js version:
   

   • Checked the Path of Node.js in Environment Variables :
   

  •  Restarted the system also.

  All of the above steps didn’t help in opening the sample in Sitecore Experience Editor.

Error-2: 
Other error with while opening Sitecore JSS Site in Sitecore Horizon 9.3.0: "Failed to render a page: Failed to render the root extension, with error: Failed to render a fragment. Status code: InternalServerError, message: "


Solution:

For Error-1: 
By default, the JSS Node engine will use your PATH variable and this setting defined on Sitecore instance (with JSS installed) at App_Config/Sitecore/JavaScriptServices/Sitecore.JavaScriptServices.ViewEngine.Node.config


In my case Sitecore JSS Framework was not able to recognize the path of Node.exe from the system/environment PATH variable.

With the help of Sitecore Stack Exchange Discussion Rendering Sitecore.JavaScriptServices.ViewEngine.Presentation.JsLayoutRenderer: Failed to start Node process, I found the solution to resolve error “Rendering Sitecore.JavaScriptServices.ViewEngine.Presentation.JsLayoutRenderer: Failed to start Node process. To resolve this: [1] Ensure that Node.js is installed and can be found in one of the PATH directories. Current PATH environment variable is:” we can add patch config which will inform Sitecore JSS engine to look for Node.js exe from particular location.
We can directly update /configuration/sitecore/javaScriptServices/renderEngines/renderEngine/instance/NodePath value at App_Config/Sitecore/JavaScriptServices/Sitecore.JavaScriptServices.ViewEngine.Node.config but good practice is to utilize the patch the config file.

After above fix, I was able to access the Sitecore JSS app in Integrated mode.

For Error-2:
After fixing of Error#1, I thought that Horizon application will be able to recognize the Node.exe path but it was not happening. Even I tried by adding the patch config for node.js in Horizon web app and tried .NET core (Horizon Application build using .NET Core Framework) related configuration also.

At the end, I placed the copy of node.exe file from C:\Program Files\nodejs to web root of Horizon Web application (Sitecore will create separate web application for Horizon) because when web application will initialize it will start looking into required resources in their own folders where it installed, for example if you are using any binaries in your webapplication then during start of application it will first find referenced binaries in local folder and after that it will look for Global Assembly Cache.

After above fix, I was able to access the Sitecore JSS app in Sitecore Horizon Application.

I hope this post will guide you to resolve the error “Failed to start Node process. To resolve this: [1] Ensure that Node.js is installed and can be found in one of the PATH directories. Current PATH environment variable is”.


Pingback:
 • Sitecore JSS installation
 • Sitecore JSS modes
 • Failed to start process node exec not found
 • Sitecore ensure that node.js is installed and can be found in one of the path directories
 • Install Sitecore Horizon
 • Sitecore Experience Platform

Share:

Monday, March 23, 2020

Sitecore JSS Application Mode Compatibility Table


Once you have decided to move implementation of your web application in headless way instead of ASP.NET MVC then after that most important architectural point is how you are going to deploy your Sitecore JavaScript Services (JSS) based headless application.

For this you have to consider many aspects and some of them are:
Is your application having any dynamic functionality where content should be severed in real time from the Sitecore instance?
Is your client more interested in Modern web tech by utilizing GatsBy? In which Sitecore CMS will just serve the content via Headless API’s to Gatsby’s ecosystem and then use Sitecore CMS Content directly into your pages using GraphQL.
Is there any business need to utilize Sitecore Experience Platform for Personalization (personalization rules, multivariate tests, etc) & Analytics? In Sitecore JavaScript Services (JSS) personalization works exactly how it does in a non-headless Sitecore site.
Is there any Business need to provide easy content authoring via Sitecore Experience Editor to Business User’s including facility to build pages using existing layout/components?
From Infrastructure point of you are you going to deploy your application on IIS or Node server?

The Sitecore JavaScript Services (JSS) SDK providing you the complete flexibility in terms of Sitecore JavaScript Services (JSS) Application Modes which will be covering above questionnaire and its very important point of Sitecore Omni channel experience which will provide the true Headless CMS capabilities without sacrificing any of the powerful marketing features you need:

Disconnected dev mode - Sitecore not required, hosts locally, uses local content data.
Connected dev mode - Sitecore required, hosts locally, content data from Sitecore.
Integrated mode - Sitecore required, hosts on Sitecore, content data from Sitecore, server-side rendering on CD server.
API-only mode - Consume personalized Sitecore layout data from any platform that understands JSON.
Headless server-side rendering mode - Server-side rendering performed on Node server, data from Sitecore CD.

All of the above Application Modes supports many different features and for this you have to deep dive into Sitecore JavaScript Services (JSS) Application Modes .

For the ease of Sitecore Community members I tried to create a Sitecore JavaScript Services (JSS) Application Modes Compatibility Table:


I hope it will be helpful for Sitecore Community and let me know if any correction required in above mentioned Compatibility Table.

We can also build Single Page Application (SPA) and Progressive Web App (PWA) in Sitecore JSS with support of  Sitecore Experience Editor functionality.

You can check functionality of Sitecore JavaScript Services (JSS) Single Page Application (SPA) at Habitat Fitness App and code base for the same present at GitHub  for your reference. Currently Habitat Fitness App sample application not having all the functionality of Progressive Web App (PWA) but you can utilize this sample app to build full-fledged Progressive Web App (PWA). 

Credit/References:

Pingback:

Sitecore JavaScript Services (JSS) Sitecore JSS Application Modes What is SitecoreJSS
Sitecore JSS connected mode Sitecore JSS integrated mode Sitecore JSS Disconnected Mode
Sitecore JSS API-only Mode Sitecore JSS Headless server-side rendering (Headless SSR) Mode Sitecore JSS Experience Editor
Sitecore Experience Platform What is a headless CMS? Sitecore JSS api
Sitecore JSS architecture Sitecore JSS angular, reactjs Sitecore JSS and sxa
Sitecore JSS sample app Sitecore JSS Personalization & analytics Sitecore JSS advantages
Sitecore JSS pros and cons Sitecore Helix Headless CMS vs Hybrid CMS

Share:

Monday, February 10, 2020

Use Sitecore MVC Rendering with Variants



Problem Statement:
In every project main requirement is reusability of deliverables in terms of server-side implementation, Sitecore Information Architecture and UI.
While working on multi-brand application where we need to rollout multiple site by utilizing the existing server-side implementation, Sitecore Information Architecture and UI, then we have to design the solution/implementation in modular, reusability and packaged manner .

We can get more information related to Packaged Solution approach at Sitecore Helix Documentation.

One of the requirements always coming to me about re-use existing Sitecore MVC Rendering with different variations like below for different brands which will be on-boarded in near future.

In the above case, its very difficult to fulfill brand’s requirements with single Sitecore MVC rendering.

Solution:
If requirements is to build the Sitecore MVC rendering which will full-fill requirement of all the brand’s in terms of styling, change in HTML layout and addition of extra fields which are already part of the template then we have to look into design of the Sitecore MVC rendering which can fulfill above requirements.

I thought of creating the design which will provide the flexibility for brands to change styling, HTML layout and addition of extra fields. 

The approach to implement above design are:

Step-1: Create the Base template
While developing any Sitecore MVC rendering we will usually crate the Data Source item for that rendering which will provide additional inputs for that rendering, so I created the Base template for rendering which will be inherited to actual data template:

/sitecore/templates/Foundation/Common/_BaseRendering/
|--Heading (Section)
|  |--Title 
|  |  |-- Single-Line Text 
|  |--Image 
|  |  |-- Image 
|  |  |-- Shared 
|  |--Summary 
|  |  |-- Multi-Line Text 
|  |--ViewPath 
|  |  |-- Single-Line Text
|  |  |-- Shared 

Inherit above template on rendering’s data template then you will be getting fields while creating the data source item for rendering:

With the help of above field, we can clone default view and create new view file as per brands need without having any development changes.

Step-2: Get the View path into Model
Store the default path of view into Constant like:

            public struct Login
{
public static readonly string ViewPath = "~/Views/Login/Login.cshtml";
}

While creating the Model object add the field for View Path also and with the help of C# code assign the value to View Path attribute: We are checking that if view path is empty in Data Source item then assign default path from the constant

        public LoginModel GetModel()
{
LoginModel model = new LoginModel();
string dataSource = RenderingContext.Current.Rendering.DataSource;
Item item = RenderingContext.Current.ContextItem.Database.GetItem(new ID(dataSource));
model.Login = GetLoginItemDeails(item);
model.Login.ViewPath = (string.IsNullOrWhiteSpace(model.Login. ViewPath) ? 
Constants.Login.ViewPath: model.Login.ViewPath);
return model;
}

The GetLoginItemDeails(item) function will return the Login data source item details, which contains the View path also:

 if (!CustomClass.IsItemNullEmpty(System.Convert.ToString(item[Templates._BaseRenderingt.Fields.ViewPath])))
                    {
                        login.ViewPath = System.Convert.ToString(item[Templates._BaseRendering.Fields.ViewPath]);
                    }

In the Controller after receiving the Model from repository assign the ViewPath: We are assigning the path of view while returning the view with model

return this.View(model.Login.ViewPath, model);

With this implementation, you can clone the Sitecore MVC rendering view and change styling, HTML layout and add extra fields, which are already present in the template without doing any code changes.

I hope this implementation approach will be helpful for Sitecore community.

Pingback:
sitecore mvc renderings
sitecore mvc rendering parameters
sitecore mvc rendering context
sitecore mvc rendering model
sitecore mvc view rendering
sitecore mvc rendering variant
sitecore sxa rendering variants
The SXA renderings and rendering variants
Sitecore Helix


Share:

Friday, January 24, 2020

Sitecore Helix : Get Redundant Fields


The Sitecore is working towards making guidelines/Principles to make Sitecore product robust. And for this Sitecore defined a set of recommended practices /design principles so that Sitecore project can be easily maintainable and extensible.

With respect to above, Helix principles defined the guidelines for template field’s that, it’s good to create the base template (interface template) for fields which being used by more than one module. With this it will work as a Interface template and modules can inherit it or extend the functionality.

In the project where many developers are working on their own module then it’s good to have discussion with Team members to identify the modules/templates which can be utilized before creating new classes/templates, and it will help to come up with base template which can be inherited in the module.

Sometimes lack of interaction between team members or strict deadline will not allow for discussion then it will directly impact the Content Tree with redundant fields in the templates and it’s difficult to review the templates when number increases at a later stage, which leads the project to inconsistent mode.

For finding the redundant fields in Templates, I have created a SQL Scripts which needs to be run against Sitecore Master DB

File Path: https://github.com/AmitKumar-AK/CT.SC/blob/master/src/Foundation/Utilities/SQLScripts/GetRedundantFields/GetRedundantFields.sql


The step-by-step details for using this SQL script present at https://github.com/AmitKumar-AK/CT.SC/blob/master/src/Foundation/Utilities/SQLScripts/GetRedundantFields/README.md

Ping back/Issues:

  • why sitecore helix
  • what is sitecore helix
  • sitecore helix and habitat
  • sitecore helix architecture
  • sitecore helix advantages
  • sitecore helix best practices
  • sitecore helix certification
  • sitecore helix documentation
  • sitecore helix dependencies
  • sitecore helix foundation layer
  • sitecore helix jss
  • sitecore helix multisite
  • sitecore helix pattern
  • sitecore helix structure

Share:

Sunday, November 24, 2019

Sitecore 9 Performance Tuning :: Sitecore box performance tuning points


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.


Figure: List of Sitecore Caches, Reference: Sitecore Community Docs

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" />

Details from: Sitecore Caches Flow, Reference: Learn Sitecore Community

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.

Azure Portal Changes:  Go to top
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: Go to top
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 .

Enable IIS HTTP keep-alive: Go to top
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.

The patch detail for patch# 223702 > Sitecore CMS 9.0 rev. 180604 (Update-2) present at https://github.com/SitecoreSupport/Sitecore.Support.223702/releases/tag/9.0.1.2.
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: )

History Table: Go to top
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.

Share:

Sitecore® Technology MVP 2020-2019

Featured Post

Sitecore Error Troubleshooting: Node.js error while setting Sitecore JSS Integrated Mode

Sitecore Error Troubleshooting: Node.js error while setting Sitecore JSS Integrated Mode Problem Statement: I was setting up th...

Total Pageviews

State Counter

Popular

About Me

My photo
Based in Bangalore, INDIA, Amit is a Sitecore MVP and MCC. He has an MCA from the U.P.T.U., INDIA and holds certifications including Sitecore and SharePoint 2007/2010. He is an contributor to Sitecore/MSDN communities and http://amitkumarmca04.blogspot.com/. Amit have experience in Sitecore, ASP.Net with C#, MVC, SharePoint, Classic ASP, VB,Macros,HTML,JavaScript,JSON,BootStrap and AngularJS.

Followers

Follow me on Twitter