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.

Read more: dynaTrace

Posted via email from Jasper-net