by Don Jones

No one likes to see the dreaded words “Web site temporarily unavailable” when they are trying visit their favorite Web site or use an internal business web service. But as business applications continue to migrate to the web, this risk increases. Fortunately, Application Performance Management (APM) is a discipline that has sprung to measure application performance in order to mitigate such interruptions. In the first part of “What You Should Know About APM”, I’ll discuss some of the basics of APM, APM solution vendors, and a few of APM’s downsides.

What is application performance management?

Application performance management – or “APM,” since it’s a serious enough discipline to warrant its own acronym – is a category of computer systems management focused on monitoring and managing the performance and availability of software applications.

That’s a mouthful, but it contains a lot of important ideas. First, APM isn’t just about monitoring application performance. We’ve been doing that for years, and while it’s an important part of the overall process, monitoring simply tells you what an application is doing. In fact, as early as a few years ago, monitoring was simply raw performance data. You could, for example, tell your boss that “the application takes five seconds to complete these types of operations.” That kind of information is essentially useless, though, because it doesn’t tell you if the application performance is acceptable or not. In other words, is five minutes good – or bad?

The next step in monitoring was applications like Microsoft Operations Manager, which applied thresholds to performance data to turn it into performance information: “Hey boss, the application is performing too slowly.” This type of monitoring – called health monitoring rather than performance monitoring – applies real-world goals and parameters to the performance data, so that we can tell when performance is “healthy,” “degrading,” “awful,” and so on. This type of monitoring is really at the heart of most APM – and honestly, I think APM would be better called application health management, or AHM, but the industry has already settled on APM so we’re stuck with it.

A tricky thing about modern applications is that they’re usually never a single, monolithic, standalone entity. In other words, you can’t determine the health of an application just by looking at the application itself. Applications today rely on databases, middle-tier components, Web services, and numerous other components which are, by some definitions, applications in and of themselves. At the top level, APM generally measures how quickly the entire application system completes specified real-world tasks – how long it takes, for example, to process a new sales order or retrieve a customer record. However, a good APM solution also has to dig down into the layers of the application and measure health and performance at each layer. Why? Well, it’s interesting to know that it’s taking 20% too long to retrieve a customer record, but it’s useful to know that it’s because of excess load on the database. Knowing about the problem and knowing where the problem exists are very different; the latter lets you start fixing the problem.

In reality, most APM solutions will measure both resources – things like memory consumption, processor utilization, and so forth – as well as the time needed to complete end-user tasks. The latter helps define acceptable service levels for the application and keep an eye on the performance of the entire application system; the former often provides clues as to why the system is performing the way it is, and offers a starting point for both troubleshooting and problem resolution.

Monitoring and measuring is the core of APM, but a typical APM solution goes a bit further. Solutions may offer the ability to record their monitoring information in order to produce historical graphs and trending charts. Solutions commonly offer numerous alerting and reporting options to help get problems resolved quickly and to provide long-term performance information. APM solutions may integrate with enterprise-level monitoring solutions (think HP’s OpenView or IBM’s Tivoli), to put enterprise applications on the same “piece of glass” as everything else IT is responsible for. A good APM solution will always focus on the end-user experience as its primary metric; other metrics may become involved to support that end-user experience and to provide troubleshooting details, but the primary “goal” is to maintain a specific level of performance as experienced by the application’s end users.

Who makes application performance management solutions?

Nearly every vendor who deals with general systems management makes some kind of APM-related solution – and many, many, many vendors exist who focus exclusively on APM solutions. Some of the “bigger” names include:

• DynaTrace
• Radware
• Computer Associates (CA)
• Hewlett-Packard (HP)
• IBM
• Halogen Software
• Precise Software
• Aternity
• OpNet
• Net QoS

There are literally hundreds more. In addition, certain niche vendors exist – such as BlueStripe – who focus on a portion of the overall APM picture, such as monitoring the health of applications but not necessarily doing higher-level APM tasks such as performance trending or reporting. Some niche solutions will focus a bit less on the monitoring and metrics side of APM and more on the troubleshooting side – in other words, when performance does grow poor, these solutions will alert you to that fact and begin an automated troubleshooting process that draws your attention to the exact application component (or components) responsible for the problem.

How does application performance management work?

Because monitoring is at the heart of APM, you’ll usually start with some kind of monitoring infrastructure. The exact methods will depend on the operating system (Windows vs. Unix vs. mainframe vs. whatever), and the platform in which the application was written (Windows-based, Java, .NET Framework, and so on). Generally speaking, an APM solution will be able to take advantage of the following:

• Operating system-level resource monitors, such as Windows’ built-in performance counters.
• Platform-level resource monitors, such as performance counters associated with a relational database management system. These may be exposed at the operating system level (this is often the case for Windows-based products), or may be internal to the platform itself.
• Framework-level resource monitors, such as performance counters exposed by the Microsoft .NET Framework. These can help monitor high-level information about the application written in the framework, such as low-level memory consumption.
• Application-level resource monitors, if any exist. These have to be specifically created and exposed by the application author.

Some application development frameworks also lend themselves to dependency injection software. For example, Spring-based Java applications support management protocols without specific development by the application’s author.
Most modern APM solutions will at the very least support Java and .NET Framework applications. Because these applications run within a framework, the framework itself can provide numerous opportunities to peer inside the application for extremely detailed performance data; applications written in a native language like C++ often provide much less detail and appear to the APM solution as a more monolithic, harder-to-monitor, entity.

What are some downsides of application performance management?

Probably the biggest hurdle for implementing APM is that most enterprises only have a small fraction of their mission-critical applications written in .NET or Java, the two frameworks that lend themselves best to the most detailed APM techniques. For example, applications like SAP are written in a much more monolithic, proprietary style and aren’t easily measured by generic APM techniques; in most cases, businesses have to acquire APM solutions specifically designed for these enterprise applications. You’ll find vendors, for example, who focus entirely on APM for SAP, or APM for PeopleSoft, and so forth.

Another difficulty that’s beginning to emerge is the heavy use of virtualization, where applications are running inside a virtual machine. Virtual machines create their own challenges when it comes to monitoring performance. For example, a performance monitor running inside the virtual machine is subject to the performance of the virtual machine itself; it won’t “see” the virtual machine as running slowly because the monitoring software “lives” inside an artificial world where virtual performance does not necessarily equate to real-world performance. Virtualized applications require new approaches, including the ability to monitor the performance of the virtual machine itself.

For example, let’s say you establish a metric that says customer records must be retrieved within five seconds. If your application – or a portion of it, such as a back-end database – is running within a virtual machine, five seconds of “virtual time” may equate to a full minute of “real time.” That is, inside a poorly-performing virtual machine – say, one that’s running on an overloaded virtual host – time runs slower. The virtual machine may perceive five seconds as having passed, while you on the outside measure a full minute. Because most end-user metrics are time based, APM has to somehow take this discrepancy into account. One way is to insert monitoring agents into the virtual machine and to monitor those agents from outside the virtual machine. That lets an APM solution compare the real-world passage of time to the perceived passage within a virtual machine, and adjust its measurements and metrics accordingly.

How does application service management differ from application performance management?

Application service management, or ASM, is related to application performance management, or APM, but differs in a couple of important ways – at least, depending on who you talk to.

Generally speaking, APM concerns itself with hard, performance-related metrics: It takes two seconds to process this particular transaction. ASM takes a more business-oriented view.

• APM normally focuses only on the performance of a single instance of an application. APM may ignore everything that’s happening in the background of that application, including more complex interdependencies. ASM, on the other hand, focuses on the performance of each layer of the application, including the operating system, hardware, and so forth. ASM does this so that it can help pinpoint the root cause of a problem.
• APM generally requires detailed instrumentation within an application, in order to collect performance information. ASM may measure observable criteria – such as the amount of memory consumed by an application process – rather than attempting to measure within the application itself.

All that is a good common description of APM and ASM. Practically speaking, however, the two terms are pretty close to one another and the differences ambiguous. Talk to an APM vendor and they’ll start describing functionality that I’ve attributed to ASM – such as monitoring the performance of discrete layers of the application. In reality, any differences between APM and ASM are mainly semantic, and if you’re discussing these subjects with someone – such as a software vendor – you should focus on actual capabilities and results, rather than semantic differences.

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.