When the applications your customers rely on break or run poorly, the business loses money. Whether it’s an ATM that runs too slowly, a credit card transaction that fails, or a Website that takes too long to load, poor application performance is bad for business.
A performance database is a collection of performance data gathered for historical analysis purposes. It lets you automatically detect and address problems before they impact customers. Typically, the database doesn’t include all the detailed data because that would be too much information to retain. The challenge is to intelligently summarize the data you need without becoming overwhelmed by the sheer volume of information.
Collecting, processing, and managing the data must be fully automatic and routine. Analyzing the data and identifying problems should also be automated as much as possible, since there’s generally far too much data to depend on human review.
A performance database gives you ready access to tools for performing automated analysis. For example, it empowers you to map application transactions and response times and then determine:
• How long it took the transactions to run
• How that response time is changing over time
• If the average time was exceeding your Service Level Agreement (SLA), or if it’s likely to, given the current rate of growth
• If there were any outliers, or exceptions, where individual transactions didn’t meet response goals
• If outliers occurred, can they be associated with other performance-related events from around the same time.
You can also correlate this information with other activities. For example, assume your service-level commitment is to answer an online query within two seconds. A transaction is retrieving data for a Website query related to customers checking their account balances. If you’re running an analysis to determine the average response time and discover the average is about 1.5 seconds, you’re meeting your objective. But imagine that yesterday at 3 p.m., it took 30 to 40 seconds for five people to get their answer. Those events were outliers—instances that didn’t meet the objective. Outliers aren’t frequent, or they would affect your averages. But even if they don’t happen often, they’re a cause for concern as they may be a warning sign of a developing problem and may have an adverse effect on a particular customer. Whatever caused the delays might have a much larger impact the next time it happens, so it’s important to be able to identify when outliers are occurring and why.
To continue with our example, perhaps the transaction retrieves data from a particular table or set of tables. Whenever certain other applications run, they might end up contending for access to the same data and cause delays. When two applications collide in this manner, you may end up with an outlier because one application has to wait for the other application to finish an operation. You might try to solve that problem by changing your concurrency strategy; for example, changing the locking rules, or even making basic changes in application design. Failure to address the issue could lead to big problems as application usage grows.
The performance of the DB2 subsystem also depends greatly on the caching performance of a variety of different pools. Being able to track the performance of these pools over time can tell you how well your storage resources are being used and whether adjustments are needed now, or soon will be needed. Exceptions that identify poor performance or even failures related to these pools can warn you of developing problems or transient peak capacity issues. All these things and more can be automatically determined and reported from a performance database.
Cutting-edge performance management tools can enable you to detect problems significantly faster and dramatically reduce mean time to repair. These tools can help you understand the business impact of application performance as it relates to user behavior—and the bottom line.
It was once common that IT had a fairly stable set of applications to support, but that’s no longer the case for most enterprises. New applications and workloads are coming in, and systems and applications are growing and shifting. Embrace this reality and develop the processes and automation needed to manage your systems’ performance.