Category Archives: Performance

Rules, Dashboards and Templates. Oh my!

Recently, we were engaged by one of our clients to investigate improvements to their existing AppDynamics configuration in order to provide greater insight in to specific areas of their application and also to provide more granular alerting capabilities. The result of this work was the creation of 11 health rules, specific to an application tier, which provided the granularity that was desired.

We then had a problem. How to deploy these health rules and the dashboard to each of the 14 application tiers in a timely and automated fashion? Secondary to this was a desire to define a standard set of Health Rules that could be easily applied to future projects as and when required.

The solution came by leveraging the AppDynamics REST API which provided a quick and simple way of exporting, and importing, health rules in bulk. Initially, the new Health Rules were entered manually for a single Application Tier and then exported using the API. The result of this operation is an XML file that described the configured rules.

It was quickly identified that the health rules defined in the XML document could be easily templated by obtaining information such as the name of the application tier and its numeric ID. A quick search and replace through the XML document resulted in a template document containing specific keywords in place of the defined tier names and IDs. A simple shell script was then used to modify this template and output rulesets for any application tier we desired, based on an input file containing a list of the application tier names and IDs that the rules were to be applied to.

Import of the resulting XML document via the API was initially performed via a REST API client which allowed the rules to be imported on a per-application basis. The result was the creation of 154 health rules in under an hour, providing a huge saving on time and effort. The API provides the ability to optionally overwrite existing rules, based on the rule name, so modifications and tweaks could be performed easily and quickly as required.

Once the health rules had been templated, the next logical step was to also template the custom dashboards we had designed. The process for this was similar to the health rules. A dashboard that had been created manually was exported via the API and templated in the same way as the health rules, replicated for each appropriate application tier, and imported via the API. This ensured each dashboard had the same look and feel and that the data being presented was consistent across all application tiers.

The completed health rules and dashboards are also providing our client with an unparalleled insight in to the performance of their application and were actively used by engineers and developers alike during a large migration and go-live event. Performance bottlenecks in each application tier were quickly identified and rectified before they became a problem. A big win for us and our client.

Our work to template the creation of health rules and dashboards ensures each and every health rule and dashboard can now be defined in a standard way with no variations or misconfigurations that can be introduced in a purely manual process. The next step is to hold the templates in source control and use a CI solution, such as Jenkins, to generate and import the rules. This would also allow any changes to the base rule sets or dashboard designs to be easily and automatically rolled out.

By Wayne, a DevOpsGuy

 

Best performing ASP.NET Session State Providers – 2013

Applications use session state. Whether session state should be used or not is a hot topic of debate, but lots of applications use session state – fact.

Recently, I was involved in troubleshooting a performance issue for a customer. As it turns out, their application was hammering session state into a Microsoft SQL Server Database. The web application was taking some fairly meaty load – 100,000’s page requests per hour spread across 15 or so web servers.  When I dug into the detail with the development team it became clear that they’d used SQL Server as a session state provider because – and I quote; “We had nowhere else to put it”.

In Microsoft ASP.NET applications this is something I’ve seen quite often, but this time it got me thinking……storing session state in SQL server seems like using a sledge hammer to crack a nut, so I decided to take a look at some alternatives.

I wanted to look beyond the typical Session State Server solution and NoSQL databases seemed the obvious route. Some are perfectly designed for Session State (some are not) and it was logical that they’d make a great alternative. But which would be the best fit?

To start off I set some rules, I wanted the following;

  1. The NoSQL database should be supported by a Session State provider which was already available. I don’t want to build one myself.
  2. Performance is paramount. I want to pick the best performing provider.

After some quick searches on NuGet and Google I discovered a couple of Session State Providers for Couchbase, Redis, MemCached and RavenDb. That was easy; four options found pretty quickly. However, when I started to try and understand the best performing provider, I just couldn’t get a clear answer.

So which is the best performing session state provider for ASP.NET?

To answer this, I needed some hard evidence, but there’s not much out there apart from conjecture, so I decided to load test each provider and find out.

In this series of blog posts I thought it would be useful to share more than just the results of my test.  So I’ll walk you through setting up each of the Session State Providers and their pre-requisites. However, since some of you won’t care about that, in the first post we’ll cut straight to the chase and look at the results.

DevOpsGuys have wide-ranging experience in using marketing leading Application Performance Management Tools, such as AppDynamics, New Relic and CloudMeter Insight. Our team would love to help you realise these same great benefits, so contact us today for more information on how we can help.