Making sense of your Dynamics CRM issues using AppDynamics

AppDynamics is a company focusing on application performance management (APM) and IT Operations Analytics (ITOA). They are based in San Francisco, CA.

The Application Intelligence market has been heating up recently even more than before. With tools that present a relatively lower price point, and better results for customers, now a lot of companies that could not afford this kind of monitoring are jumping on the bandwagon. Monitoring of complex distributed environment is a key to a company’s success, and can greatly help in the DevOps process.

AppDynamics is offering suite of tools in this space. The one we’re going to have a quick look at today is Application Performance Management (APM). The tag line for this is: “Monitor and manage complex applications to identify and resolve performance issues.”

From a deployment and performance point of view, this application is installed in the following pattern:

Controller – this is the “brain” of the application. It should be installed on a machine of it’s own, and it collects the data from all the Agents.

Agents – these are individual monitoring apps loaded on all the machines in the environment. There are various types of controllers, based on the type of application that we monitor. We have Java agents, .NET agents, PHP agents, Node.js agents, as well as database agents. Each plays it’s own role in monitoring an application, and they are pretty self descriptive. For the purpose of monitoring a Dynamics CRM environment, we look at the following agents:


As mentioned before, the recommendation is to have the Controller installed on it’s own machine. Reason for that is because it not only collects the information provided by all agents, but it allows a user direct access to monitor, investigate and report on various issues.

From a controller point of view, the impact on server performance is minimal. There is a roughly 2% performance impact on each machine where an agent is installed. From a data transfer point of view, we are looking at an average of 300-500 kb/min. from the agent to the Controller.

Once you have the Controller and an Agent installed, the auto-discovery process kicks in. After a short while, your application starts to be mapped, and you can see a visual representation in the main dashboard of the application. The following image is of a dev CRM box:


As you can see, you get a nice clear picture of what’s running on your server. The more applications you have, the more complex this diagram will be. In this instance, we’re only running Dynamics CRM on this box.

Once data starts to get collected, we can start drilling down into specific nodes to find out additional details. For example clicking on our Microsoft Dynamics CRM node gives us a multi-tabbed window with an Overview of that node, and a few additional tabs.


Going to the Slowest DB and remote Calls tab presents us with a listing of the calls and times. We can do some sorting to quickly get to the information we need.


In addition, we can identify the various back ends, and easily get an overview of the total number of calls, calls/min and errors.


Here we also have the option to drill down into a specific back end, and get specific details. This gets us to another dashboard with a slew of details, and further options to drill-down.


Here we can easily identify the slowest database calls, as well as the details of each call.


In addition, snapshots are saved for the calls outside of the specified parameters. This allows us to historically track events in the past and identify the problems at that point in time.



In a snapshot we can look at the various transactions as they happened, and get more diagnostic details.



Further more, we can drill down into a specific call, look at all the steps until the one that causes the slow-down.


Once we have identified it, we can look at additional details.



In addition to this functionality, another dashboard offers us a view into the top transactions, sorted by various categories.


Using such a tool can easily open up the communication channels between the first line support teams, the infrastructure and database support teams, the development teams, as well as the project sponsors. No more pointing fingers, and trying to identify issues blindly. Narrow down the information to a specific point in time, a specific user, and a specific call, and you can easily see why a ticket was recorded, what the issue was, and how the application performed at that time. Drill down to the code level and find out where you need to make improvements. Better visibility leads to faster time to resolution, and in the end a better, more robust application.

From a licensing point of view, you can get a free trial to test it out. I would strongly suggest that. There are also various plans, including a free Lite Plan, and various Pro Plans.

Try it and see how it can help.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a website or blog at

Up ↑

%d bloggers like this: