The One Metric to Rule Them All

  • Comments posted to this topic are about the item The One Metric to Rule Them All

  • You are talking about a measure of flow for a business system.

    You need enough flow in whatever you are measuring to establish what a normal baseline looks like.

    In price comparison sites if a provider does not supply data for 5 minutes it usually means something is wrong.

  • Well, if you know your application and your business, and there are regular patterns/thresholds/KPIs, then it's easy to spot infrastructure (or even app) issues by analyzing queues and trends.

    In the project I've been working for the past 4/5 years, that is exactly how we detect something is wrong. We have a massive OLTP, for almost-real-time processing of huge traffic volumes, across different "steps" in a sort of process chain. We know what the queue sizes are supposed to be during the different times of the day/week, so a deviation in those (or any out-of-norm backlog it the queues) immediately triggers the question, "what is happening"?

    And through the years we have learned how to quickly correlate each different queue with its corresponding bottleneck factor.

    Then, if you serve an application for business users, like we do at the far end of the processing queue, the other factor is the famous "application is slow". If I got a penny for each time I heard those words...

    I think the challenge is that you need some degree of maturity both in the application/system and in the support teams, and it takes time and effort (not to mention willingness to get involved) for the different IT support teams to reach these levels of understanding. But once it happens, I find it very useful.

    Cheers,

  • "the database was always slow - it was always slow" - I keep hearing that metric with regards to one of my applications/databases.

    That is why I started reading the free ebook (provided by SQLServercentral BTW) "Trouble Shooting SQL Server A guide for the accidental DBA" by Jonathan Kehayias and Ted Krueger. Excellent book, over 300 pages, after reading and testing the first 40 pages I already developed some sort of strategy. I don't have any metrics at all, because the application is well desinged in my humble opinion and I don't think there is anything wrong with it apart from one user who was ganted to useing it as a bit of a DW that we don't have. That user's SQL's are the 10 top SQL's from the script that is in that book. Some people blame the network, but in order to prove or disprove that theory I need a baseline and have a strategy and that takes time.

    From what I read so far there doesn't seem to be one metric.

  • We do this on a limited basis checking phone calls. If the calls are flowing as expected then that part of the business is doing fine. If not then something is wrong, might be the call tracking itself, the phone lines, who knows.

  • It is not just computing that can rely on these kind of metrics e.g. sales (number of sales in a period/value of sales in a period/average value of a sale), accounting (number of transactions in a period from a particular client) etc.

    It is nothing new. Just something I believe is underused by our industry.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply