After spending several months upgrading our custom solution to Sitecore 9.1, and launching on Azure PaaS, I have learned a lot about what it takes to eventually see the sunshine between those stormy clouds.
This is the first of a series of posts intended to help you and your team make the transition as smooth as possible.
Critical Patches
There are several patches and things that you will need to deploy that are imperative to your success on Azure PaaS.
High CPU - Excessive Thread Consumption
Sitecore traditional server roles (Content Management, Content Delivery etc) operate in a synchronous context while xConnect operations are asynchronous. Therefore, communication between your Sitecore traditional servers and xConnect are performed in a synchronous to asynchronous context.
This sync to async operation requires double the number of threads on the sync side in order to do the job. This could result in there not being enough threads available to unblock the main thread.
Sitecore handled this excessive threading problem in their application code by building a custom thread scheduler. What this does is take advantage of a blocked thread to execute the operation, thus reducing the need for the additional thread, and making this synchronous to asynchronous context more efficient.
Great stuff right? Well, the problem that everyone will be faced with is that if you are not using an exact version of the System.Net.Http library, this thread scheduler simply doesn't work!
New versions of System.Net.Http don't respect the custom thread schedulers that Sitecore has built.
With the configurations that are shipped with Sitecore 9.x, the application uses the Global Assembly Cache to reference System.Net.Http, and 9 times out of 10, it will be a newer version of this library.
Without this thread scheduler working, you will end up with high CPU due to thread blocking, and your application will start failing to respond to incoming http requests.
In my case, I saw blocking appear in session end pipelines, and also in some calls on my Content Management server when working with EXM and contacts.
More detail about his issue, and the fix is described in this article: https://kb.sitecore.net/articles/327701
When you read the article, you would think that it doesn't apply to you because it is referring to .NET 4.7.2, and if you are working with Sitecore 9.x, the application ships using 4.7.1.
The truth is that it does! You need to perform the following actions in order to fix the threading problem:
1. Apply the binding redirect to your web.config to force Sitecore to use System.Net.Http version 4.2.0.0 mentioned in the article:
2. Deploy the System.Net.Http version 4.2.0.0 to the bin folder on all your traditional Sitecore instances.
NOTE: Make sure you remove any duplicate System.Net.Http binding redirect entries in your web.config, and that you only have the one described above.
This sync to async operation requires double the number of threads on the sync side in order to do the job. This could result in there not being enough threads available to unblock the main thread.
Sitecore handled this excessive threading problem in their application code by building a custom thread scheduler. What this does is take advantage of a blocked thread to execute the operation, thus reducing the need for the additional thread, and making this synchronous to asynchronous context more efficient.
Great stuff right? Well, the problem that everyone will be faced with is that if you are not using an exact version of the System.Net.Http library, this thread scheduler simply doesn't work!
New versions of System.Net.Http don't respect the custom thread schedulers that Sitecore has built.
With the configurations that are shipped with Sitecore 9.x, the application uses the Global Assembly Cache to reference System.Net.Http, and 9 times out of 10, it will be a newer version of this library.
Without this thread scheduler working, you will end up with high CPU due to thread blocking, and your application will start failing to respond to incoming http requests.
In my case, I saw blocking appear in session end pipelines, and also in some calls on my Content Management server when working with EXM and contacts.
More detail about his issue, and the fix is described in this article: https://kb.sitecore.net/articles/327701
When you read the article, you would think that it doesn't apply to you because it is referring to .NET 4.7.2, and if you are working with Sitecore 9.x, the application ships using 4.7.1.
The truth is that it does! You need to perform the following actions in order to fix the threading problem:
1. Apply the binding redirect to your web.config to force Sitecore to use System.Net.Http version 4.2.0.0 mentioned in the article:
2. Deploy the System.Net.Http version 4.2.0.0 to the bin folder on all your traditional Sitecore instances.
NOTE: Make sure you remove any duplicate System.Net.Http binding redirect entries in your web.config, and that you only have the one described above.
Reference Data
First Issue
This first patch you need adds the ability to configure cache sizes and expiration time for the UserAgentDictionaryCache, ReferringSitesDictionary, and GeoIpDataDictionary, and the size for ReferenceDataClientDictionary cache. Without this patch, you will see high DTU (up to 100%) in your Reference Data database as there is a bug that allows the cache size to grow enormously, which leads to performance issues and shutdowns.
In order to fix the issue, you need to review the following KB article: https://kb.sitecore.net/articles/067230
In our 9.1 instance, I used the 9.0.1.2 version of the patch.
Second Issue
This first patch is not enough to fix your Reference Data woes. There is another set of Stored Procedure performance issues related to SQL when querying the Reference Data database.
Update 08/17/19
Sitecore provided an improved SQL script as the original scripts could lead to issues with the related operations in some scenarios (e.g. batch operations with GetDefinions returning only the first result).
Download the updated script here.
Redis Session Provider
First Issue
If you are on Azure PaaS, you will most definitely using Redis as your Out of Proc Session State Provider.
Patch 210408 is critical for the stability of session state in your environment https://kb.sitecore.net/articles/464570
This patch limits the number of worker threads per CPU core and also reserves threads so they can handle session end requests/threads with the least amount of delay as possible. Reading between the lines, this patch simply handles the Redis timeout issue more gracefully.
Without this, you will see session end events using all the threads and leaving no room to handle incoming http requests. After hanging for some time, they eventually end up with 502 error due to a timeout.
This patch limits the number of worker threads per CPU core and also reserves threads so they can handle session end requests/threads with the least amount of delay as possible. Reading between the lines, this patch simply handles the Redis timeout issue more gracefully.
Without this, you will see session end events using all the threads and leaving no room to handle incoming http requests. After hanging for some time, they eventually end up with 502 error due to a timeout.
After applying the patch, the timeout settings referenced in this KB article will need to be made in both your web.config and Sitecore.Analytics.Tracking.config. You also want to update your pollingInterval to 60 seconds to reduce the stress on your Redis instance as well.
Note: Depending on how much traffic your site takes on, you may need to adjust the patch settings in order to free up more threads.
So for example, you can take the original settings, and add a multiplication factor of 3 or 4. As I mentioned before, this will be up to you to determine, based on your experienced load.
Example with multiplication factor of 3:
Note: Depending on how much traffic your site takes on, you may need to adjust the patch settings in order to free up more threads.
So for example, you can take the original settings, and add a multiplication factor of 3 or 4. As I mentioned before, this will be up to you to determine, based on your experienced load.
Example with multiplication factor of 3:
For my shared session tracker update, I created a patch file like the following:
Second Issue
Gabe Streza has a great post regarding the symptoms experienced when Redis instances powering your session state are under load: https://www.sitecoregabe.com/2019/02/redis-dead-redemption-redis-cache.htmlIt's important to read through his post, and also Sitecore's KB article: https://kb.sitecore.net/articles/858026
What both are basically saying is that you will need to create a new Redis instance in Azure, so that you can split your private sessions and shared sessions. So, to be clear, you will have one Redis Instance to handle private sessions and another to handle shared sessions.
I decided to keep my existing Redis instance to handle shared sessions, and used the new Redis instance to handle private sessions.
Similar to Gabe's steps, I created a new redis.sessions.private entry in the ConnectionString.config.
I then updated my Session State provider in my web.config to the following:
Final Thoughts
These fixes have made a night and day difference on the stability of our high traffic 9.1 sites on Azure PaaS.Feel free to reach out to me on Twitter or Sitecore Slack if you have any questions.
1 comments:
With help I found it: "The assembly is supplied with VS 2017 and .Net framework 4.6.1. I checked it and was able to find this assembly in the "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\" folder"."
Post a Comment