by Don Jones

In part two of What You Should Know About APM, I’ll explore some additional topics that include APM’s place in application development and SOA, tips for collecting APM data, and a quick, real-life example of APM’s usefulness to the enterprise.

Is application performance management applicable during application development?

Absolutely yes – although it can sometimes be difficult to get developers to agree with that sentiment.

Application performance can slow for any number of reasons, many of which are within a developer’s control when writing application code. For example, poorly-written database queries can manifest as poor database performance, when in fact it’s the result of badly-written code. Poorly-written code can also cause modules within an application to execute slowly; if those modules are called frequently, then the overall application will perform more slowly than it could. Developers can use specialized tools to help monitor performance at the code level during application development; below is an example of one such tool.

This tool runs while the application is running in the design environment – in this case, Microsoft Visual Studio, although similar solutions exist for Java-based applications and other frameworks. The tool monitors the amount of time spent within each application module and, in some cases, on each line of code. Modules that account for a disproportionate amount of time are highlighted, helping developers focus on the worst-performing code. In the example shown, the performance problem has been narrowed down to a single line of code, allowing the developer to see exactly what’s running slowly and to consider alternatives for performing whatever task is involved.

Strictly speaking, this type of work is more commonly known as application quality or code quality, and isn’t usually considered a formal part of APM. That’s due in part to the fact that some vendors of APM solutions typically focus on the systems management side of the fence rather than the developer tools side of the fence. I think you need to be careful when deciding what counts as “useful” within your organization, and not rely on vendor-provided definitions. The fact is that most application performance problems start in the code, and you’ll never be able to resolve those problems fully without digging into the code. “Development” is very much a legitimate part of an application’s overall lifecycle, and managing performance at that level – and revisiting the code, if needed, when performance problems crop up in production – should definitely be a part of your larger APM strategy.

Where does application performance management fit into Service-Oriented Architecture?

Service-Oriented Architecture (SOA) is a set of principles that essentially call for managing IT resources from the viewpoint of the business’ needs and requirements, rather than from a technology-centric point of view. Under SOA, the technology infrastructure consists of business-level services such as e-mail or customer relationship management, rather than technology-centric assets like servers, networks, and applications. In the end, SOA says that businesses don’t care how those services come into being and are maintained; the business simply cares that the services exist and that they perform at an acceptable level.

The fact is, of course, that IT delivers services by means of servers, networks, and applications. Disciplines like application performance management (APM) can help make a continuous connection between what the business wants and how IT actually delivers that.

For example, a business might define desired response and availability times for an enterprise resource planning (ERP) application. This definition constitutes a Service Level Agreement, or SLA, between the business and the IT team. The business in theory doesn’t care what magic happens in the background, so long as everything described in the SLA comes to pass. If IT can meet the SLA using servers and networks, fine; if IT has to sacrifice goats and dance widdershins around the data center – well, whatever works.

APM solutions are designed to measure application performance (I prefer the term health) from that business-centric point of view. APM solutions monitor the time it takes end-users to complete specified transactions, for example, which is a very business-centric metric. Under the hood, however, this performance may be traced to technology-centric metrics. Technically this enters the space called application service management (ASM), but what happens is the monitoring solution digs into the layers of the application to measure performance at the database back-end, at middle-tier components, at the network (which carries information between application components), and so forth. This allows the monitoring solution to not only realize when application performance is exceeding SLA allowances, but to help pinpoint the root cause of the problem. That way, the business knows that performance isn’t up to spec, and the IT team has a clue about where to go and fix it.

How much data should an application performance management solution collect?

It depends on your goals.

If your goal is strictly to focus on the business metrics of an application – that is, to measure performance as experienced by end-users – then an APM solution doesn’t need to collect much. Typically, an APM solution would run monitoring agents on a few end-user computers, and measure the responsiveness of the application. Metrics would be reported to some central collection point, where overall application performance could be monitored. You’d know if you were meeting your service level agreements (SLAs) and other business-centric measurements.

If that’s your only goal, however, you’re probably not taking full advantage of what modern APM solutions can do – especially ones that bleed over into the semantically-different application service management (ASM) area.

Here’s the problem with focusing exclusively on end-user experience: Doing so only delivers the bad news. Sure, you’ll know when your application isn’t performing as desired, but what will you do about it? Many organizations see an application problem and immediately engage their entire multi-discipline team of experts: Database administrators, network administrators, senior developers, and so forth. Everyone tackles the problem from their own viewpoint, trying to find where the problem is – but none of them are equipped to really examine the entire application system. That’s where a more detailed APM (or ASM, if you prefer) solution can save the day. By digging deeper than the end-user metric and looking at network utilization, transaction hops, database statements, and other low-level technical details, the solution can pinpoint likely causes of the problem so that the right expert can tackle the problem and come up with a solution.

This is kind of the broad approach taken by applications like Microsoft System Center Operations Manager (OpsManager), pictured below. By mapping application dependencies – something you have to do manually – the monitoring solution can tell you when a problem in a dependency – such as a network router – is causing a slowdown in a higher-level business service, such as an e-mail server. But system monitoring solutions such as OpsManager only focus on extremely broad performance measurements; they don’t dig into – for example – SQL statement-level diagnoses.

More detailed solutions, such as the one pictured below, are designed to automatically map application dependencies and construct a visual representation of the entire application system. That is, the monitoring solution can “watch” an application, figure out what external assets it is using – such as databases, middle-tier components, and so on – and then automatically begin monitoring those dependencies, as well. These kinds of monitoring solutions might monitor down to database-level performance or even trace individual data statements, as well as capturing information about the network carrying all the traffic and other details. These solutions can pinpoint problems much more rapidly and accurately, enabling the right IT expert to jump on the problem and resolve it more quickly and efficiently.

So to answer the original question: A good APM solution can’t collect too much data, provided it can digest that data and use it to create a sensible, meaningful, informative display. I’ve worked with applications that can trace individual SQL statements being submitted to a database server and make recommendations about database index modifications – one example of how a really detailed APM solution can help not only identify poor application performance, but help resolve it in a semi-automated fashion.

Does application performance management really work?

Definitely. Smart Enterprise Magazine wrote an article (http://www.smartenterprisemag.com/showArticle.jhtml?articleID=210603996) describing The Kroger Co.’s struggles with an underperforming online store. Implementing an APM solution helped identify a single badly-performing SQL statement that was being executed about two dozen times for each Web page. Diving thirteen layers into the application – starting with the URL entered by the end-user all the way down to the database – the company’s IT team reworked the SQL statement, cutting product search times on the Web site in half.

That’s a huge deal, and it illustrates how deeply-buried performance problems can be in a modern, complex, multi-tier application. It also illustrates an important concept in application performance: You will be the last to know about performance problems.

Your end-users and customers will know about the problem. Many of them will simply give up on you, taking their business elsewhere in the case of customers. APM solutions help prevent that by at the very least alerting you to problems as they develop, and making sure you know what your end-users and customers are experiencing.

About the Author

Don Jones has more than a decade of professional experience in the IT industry. He's the author of more than 30 IT books, including Windows PowerShell: TFM; VBScript, WMI, and ADSI Unleashed; Managing Windows with VBScript and WMI; and many more. He's a top-rated and in-demand speaker at conferences such as Microsoft TechEd and TechMentor, and writes the monthly Windows PowerShell column for Microsoft TechNet Magazine. Don is a multiple-year recipient of Microsoft's "Most Valuable Professional" (MVP) Award with a specialization in Windows PowerShell. Don's broad IT experience includes work in the financial, telecommunications, software, manufacturing, consulting, training, and retail industries and he's one of the rare IT professionals who can not only "cross the line" between administration and software development, but also between IT workers and IT management. Don is a co-founder of Concentrated Technologies, and serves as author and series editor for Realtime Publishers.