Most Sitecore administrators and developers are probably very well aware of the power of performance counters when it comes to trouble shooting issues. But it is not well known that performance counters can actually be visualized in your Azure dashboard using Application Insights.
For this blog post I assume that you are familiar with the process to install performance counters on a server. Also, I would like to point out that it is not recommended for performance reasons to have the counters enabled all the time. They can be a great tool in resolving issues and that’s when it might help to have some graphs in the Azure portal.
In order to enable the counters for AI you can simply add them in the ApplicationInsights.config file under the Counters node:
It is worthwhile mentioning though that if you update the Application Insights version using the Nuget package manager, these changes will be overridden. As an alternative approach the performance counters can be registered with Application Insights via code which is my preferred approach:
Once the change is deployed onto the server(s) and the application is up and running the new performance counters should come through on the portal under the Application Insights Metrics section:
The data captured in Application Insights can then be further queried and shaped using Analytics that comes as part of AI or it can be exported into Power BI or other third party tools.
Here is a list of available counters that Sitecore 8 ships out of the box:
Sitecore 8.0 Performance Counters
There is more! The Sitecore performance counters are just the beginning. Using the standard .NET libraries it is very easy to create custom performance counters and hook them up the same way giving DevOps some very useful insights into the application during runtime.
In the second part of this series of blog posts I will describe what is required to deploy a Sitecore solution into the content editing environment using Visual Studio and how it can be setup.
The following steps will be executed when the Publish option from the Visual Studio Azure Cloud Service project is invoked:
- Compile source code using the ContentEditing build configuration
- Transform configuration files
e.g. web.config, connectionStrings.config…
- Extract archive of Sitecore 7.2 site root’s Website folder into web application temporary publishing folder
- Publish web application to temporary publishing folder
- Create Azure deployment package
- Upload Azure deployment package
- Deploy package
Since the Sitecore folder in the Website folder only contains Sitecore content editing related files that should not be changed I recommend to exclude this folder from being packaged and uploaded with each and every deployment package. The Sitecore folder alone is over 130 MB zipped and slows down the deployment process considerably. Instead the deployment setup below suggests to upload a zipped archive to the blob storage and extract that archive on role startup into the application folder on each web role.
Continue reading “Sitecore Azure deployment using Visual Studio Cloud Service project – Part 2”
This series of blog posts is going to describe a way how Sitecore 7.2 rev. 140526 (it most likely works with other versions as well but I haven’t tested it) can be deployed using Visual Studio and the Windows Azure integration. The big advantage that you will get from this is that the deployment can be automated using PowerShell scripts should you choose to setup continuous deployment using a build server such as TFS (yes I am biased, I like TFS). So the aim is not having to use the Sitecore Azure module for your cloud deployments.
Why am I not very fond of the Sitecore Azure module?
- The module is a black box, it’s not clear what it does under the hoods
- The module doesn’t allow automation
- It’s tedious to trouble shoot if something goes wrong
- To my understanding, the module doesn’t allow to include extra roles (e.g. worker roles) as part of the deployment
I am sure I could come up with more but I think you get the point. 🙂
This first blog post is concentrating on deploying the Sitecore databases to Windows Azure. If you have used the Sitecore Azure module you may have noticed that this is the starting point. Given that the content of this blog is only required once I decided that it won’t be worthwhile to automate the steps described.
Continue reading “Sitecore Azure deployment using Visual Studio Cloud Service project – Part 1”
Following my previous blog post here are the settings required to make the two new Australian data centers available in the Sitecore Azure module:
<datacenter name="Australia East">
<coordinates left="87%" top="84%" />
<datacenter name="Australia Southeast">
<coordinates left="85%" top="87%" />
Recently a couple of new data centers have become available to host your cloud based applications using Windows Azure.
The Sitecore Azure deployment module has been implemented in a flexible way so that the module doesn’t need to be updated when a new Azure region becomes available. If you want to add a new region simply open the App_Config/AzureVendors sub folder under your Sitecore website root and edit the Microsoft.xml file:
- Navigate to the
- Add new
<datacenter> nodes for each additional region
The name of the node needs to exactly match the region name which can be found here:
Windows Azure Regions
- Save the file and re-open the Sitecore Azure dialog from the Sitecore desktop.
When I first started to look at hosting Sitecore on Windows Azure using the module provided by Sitecore I noticed that the default setup is using in-role caching. This means that a portion of your web role’s memory will be dedicated to caching and cannot be used to serve web requests. Some people might say ‘no problem’ I just scale out if I have the need to handle more requests. In essence that’s true, but based on your solutions’ needs this could come at a cost. Hence I was wondering whether there were any alternative options available within Windows Azure.
Windows Azure offers various caching options:
- In-role Cache
- Managed Cache Service
- Azure Redis Cache
Option 2 and 3 are Services that allow you to take caching off your web roles which might be cost beneficial depending on your requirements. Using a dedicated caching service is sometimes cheaper and could work better in terms of scalability.
In this blog post I am going to describe how Azure Redis Cache can be configured in Sitecore but the same way you could use the Managed Cache Service.
Configure a new Redis cache in Windows Azure
I have chosen the Standard tier that comes with 1GB and replication. Based on your needs and the number of items that you have in your Sitecore solution you might want to consider another plan.
Continue reading “Leverage Azure Cache Services with Sitecore”