Today I am going to explain one of the major factor which can contribute to issue of Performance to your Sitecore Application in Azure PaaS, which is excessive thread calls. Below are point wise explanation of entire case study with solution.
The actual trigger for Higher thread Usage:
Calling an async code in a synchronous execution path leads to the calling thread being paused until the async part finishes (the corresponding Task object is marked as completed). Because of the specific implementation of async methods in C#, the Task object cannot be marked as complete until continuations are executed. In most of the scenarios, continuations are scheduled to be executed on thread pool threads. Therefore, the calling thread starts to depend on the availability of worker threads in the default thread pool.
One more contributor xConnect:
Sitecore xConnect is written according to high-performance application best practices, with optimized thread consumption. Its design allows for taking full advantage of async operation processing and it defines the custom scheduler to tackle excessive thread consumption.
So now you will be wondering that in regular development path we have both the above case will come, then why this issue started coming from Sitecore 9XP onward.
Simple answer(Root Cause of the issue):
Unfortunately, the recent changes in .NET Framework 4.7.2 (System.Net.Http assembly) removed the respect of custom thread schedulers. This has led to excessive thread consumption by sync-async operations.
It is possible to configure a Sitecore application to use a previous version of the System.Net.Http.dll assembly instead of the .NET Framework 4.7.2 version.
Copy the System.Net.Http.dll file from the C:\Program Files (x86)\Microsoft Visual Studio\[*]\Professional\MSBuild\ Microsoft\Microsoft.NET.Build.Extensions\net471\lib folder to the \bin folder of Sitecore. Assembly file version 4.6.26011.01.
– where [*] should be replaced with relevant Visual Studio version (2017 or 2019).
Configure Sitecore to use the new assembly version instead of the assembly from GAC:
- Remove all existing binding redirects for System.Net.Http from the Web.config file.
- Add the following binding redirect to the Web.config file:
<dependentAssembly> <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" xmlns="urn:schemas-microsoft-com:asm.v1" /> <bindingRedirect oldVersion="0.0.0.0-188.8.131.52" newVersion="184.108.40.206" xmlns="urn:schemas-microsoft-com:asm.v1" /> </dependentAssembly>
When version 220.127.116.11 of System.Net.Http library is used, it contains an implementation of the HttpClient class that respects custom schedulers. Therefore, synchronous methods of xConnect client require just a single thread to complete a request.