Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

If it ain't broke, application performance monitor it

Application performance monitoring fixes a system before it breaks. IT strategist Scott Sehlhorst offers insight into preventive performance testing.

When and why should we application performance monitor [APM]?

As a product manager who worked for nearly a decade as a mechanical design engineer, then another almost-decade writing software, I get more excited about application performance monitoring than I probably should. APM is where the behavior of software (and hardware) systems intersects with the process-centric view of engineering and with the customer-centric views of value and relevance.

You don't want to discover that searches are taking too long only by investigating a gradual decline is usage, or a loss of revenue.

One way to approach the prioritization of investments in your software is the old curmudgeon's favorite -- If it ain't broke, don't fix it. How do you know if something is broken? How do you define "broken?"  Everyone will agree that if something doesn't work, it is broken. When you think about it a bit more, from a product perspective, if something doesn't work well enough, it is just as broken. An example may demonstrate the value of APM better than a discussion in the abstract.

Business analysts will separate the concepts of working (at all) and working-well-enough in terms of functional and nonfunctional requirements. A functional requirement may be for a content-streaming website to filter available content based upon the detection of a user's location (because of geographically fenced licensing deals prohibiting the streaming of some content in some locales).  A nonfunctional requirement may be for the website to display (at least some of) the filtered-by-location search results within one second of the user's query being submitted.

As the website developer, imagine the initial release of your site is only available to users in one geographic region. Perhaps you physically prevent connections from outside a single geographic region.  You then make sure that the only content that is available for streaming is content available in that region. You've satisfied your functional requirement. You run some performance tests and find that the website is also meeting the nonfunctional requirement for presenting search results.

A few months later, you expand your market to include users from multiple regions and content that is available in those areas. You now have to add capabilities to support multiple locations, implement detection of user-geography and filter search results to include only content that is available in a particular region. You define and automate tests that assure continued compliance with the functional requirements.

Now, what about the nonfunctional requirement of speedy performance?

You could run some performance tests and satisfy yourself that things are working fine. Within the confines of discrete product releases, this can work acceptably. But what happens to your system as your number of users grows over time, as you add more content, support more regions and improve your search engine's ability to return relevant results?

APM is useful for making sure you continue to deliver against the nonfunctional requirement of timely performance. If you aren't monitoring how the changes to your environment (users, content, etc.) affect the performance of your system, you won't know when things are about to break, and you might not discover until long after they've broken. You don't want to discover that searches are taking too long only by investigating a gradual decline in usage or a loss of revenue. 

You want to know before the process goes "out of control" (in engineer jargon) that changes need to be made. Wouldn't it be great if you knew that the average search took 0.5 seconds, and wouldn't you want to be alerted when searches started taking more than 0.9 seconds? This would give you the opportunity to improve things -- add servers, optimize code, index databases, etc. -- before you break the nonfunctional requirement.

If you application performance monitor, its value will become obvious. Think of it as preventive maintenance. Software isn't just about building features or products. Software products are created to be used, and it is using the product that makes it valuable. By monitoring the performance of the software, you can assure that it is performing as required, know when it is not and know when it is about to break, before it breaks.

Are you considering application performance monitoring? Let us know, and our site experts will offer advice!

Dig Deeper on Topics Archive

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

In addition to application performance, IT managers also need to think about infrastructure performance. By using tools such as Load Dynamix in a pre-production environment, IT managers can simulate performance requirements of real applications and know the breaking points of their infrastructure before live deployment. This will eliminate any performance surprises.