Database metics - thoughts and measurements

If I were to ask you 'what are the (database) metrics?', what do you think I'm asking? Thats an interesting question and something that requires some thought so lets handle this by actually looking at the following two alternative questions. 'What am I trying to archive [with database metrics]?' and 'how will I know when I have achieved it [by having database metrics]'?

Define the problem

What are we really doing
What are we trying to achieve?

• Know how much capacity we have
• Know that our databases are fast

How do we know when we have achieved it?

• When we can forward plan upgrades when we are near a capacity limit
• To be alerted of when things are not fast we can we investigate

So, what is capacity

Capacity is knowing how much extra we can do without making things 'slow'. Its a nice statement but it doesnt really mean much as the words are not quantified.

What is fast?

If I were to say that in a database, query (a) took 1 second to run and another query (b) took 10 seconds to run, what does it mean? If a website takes 10 seconds to render a search page and 5 seconds to render a home page, is it fast? Its all relative and very subjective and we really need to define it.

So lets redefine what we are measuring as 'response time'. The time it takes from start to finish. But going back to the statement, is it 'fast', we'll we dont actually know. We need to come up with a definition of fast. Lets call this definition our 'goal'.


What are our goals?

A 'goal' is what we want to archive and being 'fast' or 'slow' is relative to the goal. A database makes up part of the stack - so should we be setting the goals for the application and not the database? Maybe, but lets assume no.


Examples of goals

• How fast should the home page be?
• How fast should a search page be?
• How fast should a details page be?

We need these goals as we cannot set metrics without knowing what is acceptable behaviour.  We need these goals as time and optimisation is finite. If you were to fix one thing at the expense of another, what would it be and what loss would you be willing to accept?

Goals and optimisation
Optimise your infrastructure or solution to meet your goals. For example adding an index in a database will make some things fast (eg reads against that specific column) though it will make some things slow (writes to that table as the new index will need to be updated). To extend that simple example,  if its important to have really quick write access and we dont care about read access then we shouldnt add an index.


So what to measure

Measure capacity

In databases, the universal scaling law can be used to measure capacity. The law states at specific concurrency throughputs, we can measure the overall throughput and state what our peak concurrency (eg capacity) is.


Measure how fast (eg measure the response time)

Set goals for what you want to achieve and drill down the response time from the database to ensure that the database component is able to meet the response time SLA. Different pages (eg home page, search results,details page) should have different goals therefore the response time for the database should set for each.