The four magic questions of performance

Answering these four simple questions is the key to tackling any performance problem. The challenge is in getting the answers from your Oracle-based applications. We explore the questions and reveal how you can get the answers.

We’ve all experienced frustration, waiting while a web page loads or a business application takes an age to process something. Poor user experiences cost your organization money and risk damaging its reputation. And with so many companies now using customer experience as a differentiator, any that lag behind are at a serious disadvantage.

But how do you go about addressing this type of slow performance? Enterprise applications can be incredibly complex, relying on a variety of servers, storage, networking infrastructure, databases and potentially other applications and services. Identifying what exactly is causing the slow application performance can be exceptionally challenging. The monitoring tools used by your administration teams only look at things that are easy to measure – and consequently don’t show you for certain where your time is being spent. Moreover, it’s not uncommon for each team to be able to ‘prove’ it’s not their cog slowing down the machine.

The four magic questions of performance enhancement

The secret to successfully diagnosing and tackling performance problems with applications running on Oracle databases is to answer four key questions. Let’s look at each in turn.

How long is the slow task taking?

There are really two parts to this question: before you can ask how long your task is taking, you have to define what exactly that ‘task’ is. Is a screen or web page slow to load? Is some batch job taking too long? Or does the whole system feel slow? No matter what the problem is, it’s the business that should define it, rather than your application or technology teams. If there’s more than one task that’s slow, rank them in order of business importance. If the list is short, great. If it’s long, the message is that you’ll get to everything in good time, but will start with the problem that’s causing the business the most pain. Having defined what you’re aiming to speed up, you need to know how long it’s taking now – in hours, minutes and seconds.

Measuring in this way ensures there’s total focus on the actual user experience of the task. At this stage, identify the business’s expectations about how long the task should be taking. Do you have a customer SLA requiring this task to finish within three seconds, on 99.9% of executions? Or did it take 10 minutes last month and now takes an hour, and you want to get back to where you were? Be careful not to over-commit at this stage, because you don’t yet know what’s possible or practical. That understanding will come out of the next steps.

Why is it taking so long?

Having defined exactly what you’re looking at, you need to ascertain why your task is taking the time it is. As we’ve touched on, standard monitoring tools look at what the system as a whole is doing, not the individual application. For example, your system-level monitoring tool may show CPU running at 100%, but you don’t know for sure whether your slow-running task is using the CPU, or how long it’s spending doing so.

If you assume your task is doing what your system-wide statistics say your system is doing, you may be thrown off the scent. This is why you need a way to see exactly how your application spends your time, from the moment you start the task in question to the moment it concludes. Method R Workbench creates a table called a profile, showing exactly where your application has spent your time. It’s broken down into the different SQL or PL/SQL statements, database calls and operating system calls the application is making, and shows how long each one takes. Many problems are recurrent anti-patterns that you can easily learn to identify. Parsing SQL statements inside of loops, processing one row at a time, and using inefficient access paths to your data, for example, are easy patterns to spot.

What if…?

Having identified what your application is doing, the next step is to identify opportunities to make it finish the task more quickly. The aim here is to eliminate any waste in how the application runs. The profile guides the way, making it easy to predict how much time you’ll save by making a particular change – the ‘what if?’ Doing this means you’re basing your remedial actions on evidence, instead of spending time making trial-and-error changes to your software or infrastructure, when you have no idea in advance how much they’ll help.

Of all the performance improvement opportunities you can find, the business can decide which ones to carry out. Pick those with the best cost/benefit/risk profile. Once you’ve identified that what you’re proposing will deliver the improvements you need, it’s time to roll out the change. After you implement it, measure performance again to ensure the new reality is in line with your predictions from the ‘what if’ phase. This data-driven approach will make everyone on your team more competent and confident about delivering high-performance to your users.

What else?

The next question is ‘what else?’ After you make your task go faster in the first instance, there may be opportunities to make it faster still. You can identify these by profiling the process again. In one high-profile case, we took a two-minute process down to one minute, then 30 seconds, then 10 seconds, and finally to less than one second. We achieved this by executing four iterations of ‘how long?’, ‘why?’, ‘what if?’ and ‘what else?’ With the ability to answer these four questions objectively, you can efficiently and methodically tackle performance issues that affect your customer experiences.

Why you need specialist tools to answer these questions

These questions in themselves are common-sense. The difficultly many organizations face is that they don’t have the capabilities to answer them. The normal Oracle tools don’t collect the data you need, and even if DBAs or application developers were to gather it in another way, understanding and analyzing it can be challenging. This is where the Method R Workbench software that Cintra uses is truly revolutionary, because it makes it easy to answer these four questions. It’s your fast track to better performance and user experiences. So with customer experience already a key differentiator in many sectors, you need to act now to ensure your Oracle-based applications are delivering the best-possible performance. Cintra’s Method R approach, using laser-focused response-time data, has a track record of delivering results fast. In our next pieces, we’ll look at three use cases for the Method R technique: tackling slow-running applications, building high-performance applications, and planning for your cloud transition.

Insights