Tag: Diagnostics

Performance tuning of Sitecore SPEAK components

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

Today I am going to explain you how you can reduce the time taken for loading by SPEAK components in your Sitecore application.

In order to reduce load time of SPEAK components after website modification, you can alter the compilation element in the web.config by adding the optimizeCompilations attribute to it as follows:

<compilation ...  optimizeCompilations="true">

Actual Implementation in web.config file looks like:

c

Adding this attribute will make ASP.NET re-compile only the files that were explicitly changed and leave all the other files intact.

Please note that if optimizeCompilations is true, you might encounter some issues during development after re-compilation. According to the MSDN article

When you change a top-level file only the affected files are recompiled. This saves time but can cause run-time errors depending on the type of changes you make to a top-level file.

Please check the Optimizing Dynamic Compilation part of the a aforementioned article for more details.

Happy Learning Sitecore !!!!

Advertisement

Disabling ARR’s Instance Affinity in Sitecore Azure Websites

Azure
~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

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.

Advantages:
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.

Dis-Advantages:
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?

  1. Client connects to an Azure Web Sites website
  2. ARR runs on the front-end Azure server and receives the request
  3. ARR decides to which of the available instances the request should go
  4. ARR forwards the request to the selected server, crafts and attaches an ARRAffinity cookie to the request
  5. The response comes back to the client, holding the ARRAffinity cookie.
  6. 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)
  7. When the client submits a subsequent request, it includes the cookie in it
  8. When ARR receives the request, it sees the cookie, and decodes it.
  9. 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
  10. 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
8407.blogpicture.png-550x0
 
This is how the affinity cookie looks:
 
5773.bp2.png-550x0
 

Disabling the affinity can be done in different ways: (Every one prefer that last way explained)

  1. 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: 
     
    headers.Add(“Arr-Disable-Session-Affinity”, “True”);
     
  2. 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: 

6765.bp3.JPG-550x0 

There is one more way yo disable this is which require us to follow below steps.
  1. Go to Azure App service.
  2.  Then go to Configuration.
  3. In configurations you will find General settings tab click on it.
  4. Here in this tab you will find the Sections called Platform settings.
  5. In this sections you will find the ARR affinity radio button.
  6. As per requirement you can disable it.(by default this is on)

ARR

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.

Happy Learning!!!!

Profiling a Sitecore Web App on Azure App Service

Azure
~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

Today I am going to help you with how you can collect .NET Profiler Trace in Azure App Service. With out any further details we will jump in below details.

The Diagnostic Tools options under the Diagnose and Solve blade for Azure App Services has been live for a few months now and has many tools that help you troubleshoot apps based on their application stack. In this post, we are going to cover the Collect .NET Profiler Trace option in detail and how you can use it to troubleshoot a slow or a failing ASP.NET based Web App.  Profiler tool helps in collecting an on-demand trace that lets you identify the underlying .NET exceptions, time taken in the various request processing pipeline stages and even lets you drill down into exact methods within the application code that are taking time. It is extremely useful in situations where the problem is happening right now and you want to collect some data to identify the root cause of the issue. Profiling is designed for production scenarios and is based on ETW (Event tracing for Windows) . The analysis component of the profiler uses the TraceEvent library to generate a report that helps you drill down in to the problems in matter of a few minutes. It should be noted that no changes are made to your Web App code or your configuration during the collection or the analysis phase. In fact, the web app is not even restarted as a result of capturing this trace. The captured trace has ETW events emitted by the IIS and the ASP.NET providers along with stack traces captured at the CPU level. You can use this tool to efficiently troubleshoot delays which are relatively small (less than a second too) without impacting the run-time performance of the application. At this point, the profiler works only for ASP.NET web apps only and ASP.NET Core support might come soon.

How to Collect the Trace

To collect the trace, go to the App Service in your Azure PaaS, then go to  Diagnose and Solve Problems  and choose the Collect .NET Profiler Trace option under Diagnostic Tools option and click on Collect Profiler Trace. Unless you have isolated that only a specific instance is failing, it is best to just select all the instances on which your Web App is running.  Add thread report option – With this option enabled, a thread report of all the threads in the process is also collected at the end of the profiler trace. This is useful especially if you are troubleshooting totally hung processes, deadlocks or requests taking more than 60 seconds. This will pause your process for a few seconds until the thread dump is generated. This option is NOT recommended if you are experiencing high CPU on the instance because if the instance is under stress, it might take a long time to even start a new process to collect the thread dumps. Clicking the Collect Profiler Trace will start profiling the Web App and the wizard will show progress of various steps involved.  Once the profiler trace is started, reproduce the issue by browsing the Web App. If you have a Web App running on multiple instances, make sure to browse a few more times to ensure that the requests to the web app get captured in the profiler trace. The default duration for which the profiler trace runs is 60 seconds and during this 60 seconds, all the requests that were made to the Web App get captured in the profiler trace. It is important to note that the profiler trace only has information about the requests that were captured in these 60 seconds (It is possible to increase this duration as mentioned below in this article) After 60 seconds, the profiler automatically stops, and an analysis component gets triggered that starts analyzing the profiler trace that just got captured. After the analysis finishes, a link to view the profiler report for every instance serving the web app is generated and you click on the Open Report button to view the Analysis report. 

Happy Learning