Michael Kopp About the Author

Michael is aTechnical Product Manager at Compuware. Reach him at @mikopp

Application Performance Monitoring in production – A Step-by-Step Guide – Part 1

Setting up Application Performance Monitoring is a big task, but like everything else it can be broken down into simple steps. You have to know what you want to achieve and subsequently where to start. So let’s start at the beginning and take a top-down approach

Know what you want

The first thing to do is to be clear of what we want when monitoring the application. Let’s face it: we “do not want to” ensure CPU utilization to be below 90 percent or a network latency of under one millisecond. We are also not really interested in garbage collection activity or whether the database connection pool is utilized. We need to monitor all of these things in order to reach our main goal. And the main goal for this article series is to ensure the health and stability of our application and business services. To ensure that we need to leverage all of the mentioned metrics.
What does health and stability of the application mean though? A healthy and stable application performs its function without errors and delivers accurate results within a predefined satisfactory time frame. In technical terms this means low response time and/or high throughput and low to not existing error rate. If we monitor and ensure this than the health and stability of the application is likewise guaranteed.

Define your KPIs

At first we need to define what satisfactory performance means. In case of an end-user facing application things like first impression and page load time are good KPIs. The good thing is that satisfactory is relatively simple as the user will tolerate up to 3-4 seconds but will get frustrated after that. Other interactions, like a credit card payment or a search have very different thresholds though and you need to define them. In addition to response time you also need to define how many concurrent users you want, or need, to be able to serve without impacting the overall response time. These two KPIs, response time and concurrent users, will get you very far if you apply them on a granular enough level.
If we are talking about a transaction oriented application your main KPI will be throughput. The desired throughput will depend on the transaction type. Most likely you will have a time window in which you have to process a certain known number of transactions, which dictates what satisfactory performance means to you.
Resource and Hardware usage can be considered secondary KPIs. As long as the primary KPI is not met, we will not look too closely at the secondary one. On the other hand, as soon as the primary is met optimizations must always be towards improving this secondary KPI.

If we take a strict top-down approach and measure end-to-end we will not need more detailed KPIs for response time or throughput. We of course need to measure more detailed than that in order to ensure performance.

Know what, where and how to measure

In addition to specifying a KPI for e.g. the response time of the search feature we also need to define where we measure it.

The different places where we can measure response time

The different places where we can measure response time

This picture shows several different places where we can measure the response time of our application. In order to have objective and comparable measurements we need to define where we measure it. This needs to be communicated to all involved parties. This way you ensure that everybody talks about the same thing. In general the closer you come to the end user the close it gets to the real world and also the harder it is to measure.

We also need to define how we measure. If we measure the average we will need to define how that is calculated. Averages themselves are alright if you talk about throughput, but very inaccurate for response time. The average tells you nearly nothing about the actual user experience, because it ignores the volatility. Even if you are only interested in throughput volatility is interesting. It is harder to plan capacity for a highly volatile application than for one that is stable.  Personally I prefer percentiles over averages as they give us a good picture of the distribution and thus the volatility.

50th, 75th, 90th and 95th percentile of End User Response time of the Page Load

50th, 75th, 90th and 95th percentile of End User Response time of the Page Load

In the picture we see that the page load time of our sample has a very high volatility. While 50 percent of all page requests are loaded in 3 seconds, the slowest 10 percent take between 5 and 20 seconds! That not only bodes ill for our end user experience and performance goals, but also for our capacity management (we’d need to over provision a lot to compensate). High volatility in itself indicates instability and is not desirable. It can also mean that we measure the response time not granular enough. It might not be enough to measure the response time of e.g. the payment transactions in general. The CreditCard and DebitCard payment transaction might have very different characteristics and we should measure them separately. Without doing that type of measuring response time becomes meaningless because we will not see performance problems and monitoring a trend will be impossible.

This brings us to the next point, what do we measure? Most monitoring solutions allow the monitoring either on an URL level, servlet level (JMX/App Servers) or Network level. In many cases the URL level is good enough as we can use pattern matching on specific URI parameters.

Create measures by matching the URI of our Application and Transaction tyoe

Create measures by matching the URI of our Application and Transaction tyoe

For Ajax, WebService Transactions or SOA applications in general this will not be enough. WebService frameworks often provide a single URI entry point per application or service and distinguish between different business transactions in the SOAP message. Transaction oriented applications have different transaction types which will have very different performance characteristics, yet the entry point to the application will be the same nearly every time (e.g. JMS). The transaction type will only be available within the request and within the executed code. In our Credit/Debit card example we would most likely see this only as part of the SOAP message. So what we need to do is to identify the transaction within our application. We can do this by modifying the code and provide the measures ourselves (e.g. via JMX). If we do not want to modify our code we could also use aspects to inject it or use one of the many monitoring solutions that supports this kind of categorization via business transactions.

We want to measure response time of requests that call a method with a given parameter

We want to measure response time of requests that call a method with a given parameter

In our case we would measure the response time of every transaction and label it as a DebitCard payment transaction when the shown method is executed and the argument of the first parameter is “DebitCard”. This way we can measure the different types of transactions even if they cannot be distinguished via the URI.

Think about errors

Apart from performance we also need to take errors into account. Very often we see applications where most transactions respond within 1.5 seconds and sometimes a lot faster, e.g. 0.2 seconds. More often than not these very fast transactions represent errors. The result is that the more errors you have the better your average response time will get, that is of course misleading.

Show error rate, warning rate and response time of two business transactions

Show error rate, warning rate and response time of two business transactions

We need to count errors on the business transaction level as well. If you don’t want to have your response time skewed by those errors, you should exclude erroneous transaction from your response time measurement. The error rate of your transaction would be another KPI on which you can put a static threshold. An increased error rate is often the first sign of an impeding performance problem, so you should watch it carefully.

I will cover how to monitor errors in more detail in one of my next posts.

What are problems?

It sounds like a silly question but I decided to ask it anyway, because in order to detect problems, we first need to understand them.

ITIL defines a problem as a reoccurring incident or an incident with high impact. In our case this means that a single transaction that exceeds our response time goal is not considered a problem. If you are monitoring a big system you will not have the time or the means to analyze every single violation anyway. But it is a problem if the response time goal is exceeded by 20% of your end user requests. This is one key reason why I prefer percentiles over averages. I know I have a problem if the 80th percentile exceeds the response time goal.

The same can be said for errors and exceptions. A single exception or error might be interesting to the developer. We should therefore save the information so that it can be fixed in a later release. But as far as operations is concerned, it will be ignored if it only happens once or twice. On the other hand if the same error happens again and again we need to treat it as a problem as it clearly violates our goal of ensuring a healthy application.

Alerting in a production environment must be set up around this idea. If we were to produce an alert for every single incident we would have a so called alarm storm and would either go mad or ignore them entirely. On the other hand if we wait until the average is higher than the response time goal customers will be calling our support line, before we are aware of the problem.

Know your system and application

The goal of monitoring is to ensure proper performance. Knowing there is a problem is not enough, we need to isolate the root cause  quickly. We can only do that if we know our application and which other resources or services it uses. It is best to have a system diagram or flow chart that describes our application. You most likely will want to have at least two or three different detail levels of this.

  1. System Topology
    This should include all your applications, service, resources and the communication patterns on a high level. It gives us an idea of what exists and which other applications might influence ours.
  2. Application Topology
    This would concentrate on the topology of the application itself. It is a subset of the system topology and would only include communication flows as seen from that applications point of view. It would end when it calls third party applications.
  3. Transaction Response Flow
    Here we would see the individual business transaction type. This is the level that we use for response time measurement.

Maintaining this can be tricky, but many monitoring tools provide this automatically these days. Once we know which other applications and services our transaction is using we can break down the response time into its contributors. We do this by measuring the request on the calling side, inside our application and on the receiving end.

Show response time distribution throughout the system of a single transaction type

Show response time distribution throughout the system of a single transaction type

This way we get a definite picture of where response time is spent. In addition we will also see if we loose time on the network in form of latency.

Next steps

At this point we can monitor health, stability and performance of our application and we can isolate the causing tier in case we have a problem. If we do this for all of our applications we will also get a good picture how the applications impact each other. The next steps are to monitor each application tier in more detail, including used resources and system metrics. In the coming weeks I will explain how to monitor each of these tiers with the specific goal of allowing production level root cause analysis. At every level we will focus on monitoring the tier from an application and transaction point of view as this is the only way we can accurately measure performance impact on the end user.

Finally I will also cover System Monitoring. Our goal is however not to monitor and describe the system itself, but measure how it affects the application. In terms of Application Performance Monitoring, system monitoring is an integral part and not a separate discipline.

Comments

  1. Interesting, but what kind of tool do you use to aggregate and process such a set of data coming from really distinct sources ?

    What strategy is the most suitable : live monitoring or deferred analysis (maybe based on logs) ?

    David

  2. First of all, good question. I will answer in more details in the coming posts, this is good input for me!

    In short though:

    I’m obviously baised towards dynaTrace on the tool question. In general though I would recommend to use a single tool that can record as much of the data you need as possible. Exactly because it is nearly impossible to aggregate the data from different tools effectively. An additional requirement is that the tool you choose should be able to gather data from other sources and correlate that. This is suitable for metrics that are not transaction based in the first place like os metrics, database metrics, jms metrics and so on.

    As for strategy: live monitoring. automated analysis where possible and deferred analysis where not, but on the same data, not different one.Not based on log files though, they lack transaction context, are complicated in distributed environments and have a lot of overhead when you start thinking about it.

    if you have more questions, don’t hesitate to post them I will try to answer all of them in the upcoming posts.

  3. Excellent post. Looking forward to subsequent ones..

    You mentioned that we monitoring based on logs is not a good option. can you please throw more light on it. What alternatives one should try in case of deferred monitoring ?

  4. I will explain what to look for in a monitoring solution in my next post. I think deferred monitoring does not really work, after all monitoring is about reacting to current issues as well. what you might mean is deferred analysis, I will cover this in the series.

    As there is interest and it is clear a topic for many, I think I will also spend another one logging and why it is not a monitoring solution.

    In short, the problem with logging IMO is:
    * Performance overhead
    * Distributed Nature, try tracking what belongs together
    * lack of Context and cross app/jvm/transaction analysis not easily possible

    logging is good for errors, stacktraces and in general just make sure that the info is stored somewhere.

  5. C++ “delete” keyword must be optional for java, Must be added along GC.

  6. Excellent post. The section regarding errors is great advice. I particularly like the tip to omit erroneous data from response time measurements.

  7. To monitor a performance of any application, it requires manual as well as an automation testing. Such tools will provide you the step by step process and alternatives of analyzing each elements.

  8. Mine is a question, what is the impact of enabling performance monitoring on the WAS console?

  9. Determining KPIs is extremely important. You need to know what exactly it is that the software should be monitoring on behalf of your business.

  10. Vitaly Grinberg says:

    Lets face it, I would like to know why the specific workload drives the CPU usage high and what is the contribution of GC to the CPU usage. By the same token, I am interesting in knowing why the connection pool is running at maximum and how it impacts the workload respone time.

Comments

*


six − 3 =