Today I am going to introduce my new Module for Sitecore Azure PaaS. This module is called Azure Worker Exchanger details for this are as below.
What is Azure Worker Exchanger?
Azure Worker Exchanger Module is a facility created in association with Microsoft Azure Worker API to kill and replace any of the corrupt or non-performing workers created in Azure PaaS. This module should be used only when any worker process is showing a spike in performance and behaving abnormally or got corrupted, to analyze these below are the symptoms.
- Website loading slowly.
- Some of the users are not able to visit the website.
- Azure is throwing many alerts for performance issues.
- Azure matrics showing spikes for performance.
How to use this Module?
- Download the Module here.
- Install on CM role with Sitecore Package Installer.
- Once done you can navigate to the below URL to find the Form.
- Once the form is open you need to supply few details about your Azure Web app. (These are very simple and exactly as mentioned in below photo)
- Once you filled the form submit it.
- You will get a response message back.
- After that wait for 5-10 minutes for Azure to settle everything.
- Once everything is settled you need to go to the Azure Web app and open a kudu to see a new worker created with new underlying resources.
Happy Learning !! Keep Learning !!
Today I am going to explain quick learn for usage of Pre-complied view in Sitecore 9XP. Enabling Pre-compiled MVC views gives boost to performance in Azure PaaS environment, it is considered as one of the performance tuning parameter in Sitecore Azure PaaS environment and Sitecore Managed Cloud.
By pre-compiling views you will benefit from the following:
- Compile time checking of errors. Usually, Razor files are compiled when they are first required. By pre-compiling your Razor views you remove the source of runtime bugs.
- Faster load time. The SitecoreRazorViewEngine will start to load your views from an assembly (.dll file) rather than a view (.cshtml file).
- Once the Razor-Generator is Configured for your Visual Studio Solution you can follow below steps
- To enable Razor-Generator Check this link.
Perform the following to pre-compile MVC views:
- Go to the below folder path. wwwroot\youewebsitefolder\App_Config\Sitecore\Mvc
- Here you will find the config file with the name “Sitecore.Mvc.config”
- In this file search for term “<precompilation>”.
- And under <precompilation> node add below configuration highlighted in green. don’t forget to change the name to your assembly name. <precompilation>
<assemblyIdentity name=”Sitecore.Mvc” />
<assemblyIdentity name=”YourAssemblyName” />
Happy Learning Sitecore !!!!
Today I am going to help you in different aspect of scaled environment in Azure where I will explain what is ARR in scaled Sitecore Azure instances. So without delaying we will start this with below pointer which will explain all the things related to this.
What is ARR Affinity?
Application Request Routing (ARR) is a feature where when a client (or browser) request to any Azure based website, a cookie will be created and stick to the first time request received web site instance.
The same cookie will be used for subsequent requests from this client or browser and these requests will be guided to the same web site instance the one which was served for the first time.
With this feature, we can get an advantage if in case the web site instance is maintaining lots of data in it’s memory and moving the subsequent requests to other instance leads to copy entire data to other instance and this is a more performance and pain to the system.
We can see many disadvantages when compared with advantages. If a client request and unfortunately the sticky instance is not available, this request cannot be guided to any other available instance instead it will send an unavailable message to the client.
Also, In case if an instance is a too much load with other request and this request will be in request queue instead can guide to other instance to balance the load.
How ARR Affinity works?
- Client connects to an Azure Web Sites website
- ARR runs on the front-end Azure server and receives the request
- ARR decides to which of the available instances the request should go
- ARR forwards the request to the selected server, crafts and attaches an ARRAffinity cookie to the request
- The response comes back to the client, holding the ARRAffinity cookie.
- When the client receives the request, it stores the cookie for later use (browsers are designed to do this for cookies they receive from servers)
- When the client submits a subsequent request, it includes the cookie in it
- When ARR receives the request, it sees the cookie, and decodes it.
- The decoded cookie holds the name of the instance that was used earlier, and so ARR forwards the request to the same instance, rather than choosing one from the pool
- The same thing (steps 7-9) repeat upon every subsequent request for the same site, until the user closes the browser, at which point the cookie is cleared
This is how the affinity cookie looks:
Disabling the affinity can be done in different ways: (Every one prefer that last way explained)
- In your application
To control this behavior in an application, you need to write code to send out a special HTTP header, which will tell the Application Request Router to remove the affinity cookie. This header is Arr-Disable-Session-Affinity, and if you set it to true, ARR will strip out the cookie. For example, you could add a line similar to this to your applications’ code:
- In a site configuration
If you prefer to have it completely disabled, you could have ARR remove the cookie always by having IIS itself inject that header directly. This is done with a customHeaders configuration section in web.config. Simply add the following into your web.config, and upload it to the root of the site:
There is one more way yo disable this is which require us to follow below steps.
- Go to Azure App service.
- Then go to Configuration.
- In configurations you will find General settings tab click on it.
- Here in this tab you will find the Sections called Platform settings.
- In this sections you will find the ARR affinity radio button.
- As per requirement you can disable it.(by default this is on)
To test this you need to go into HTTP header and check the value is coming or not. Another simple way is once you disabled it you can clear your browser cookies and load the website again and check in cookies sections and you will find that ARR cookie is not created.