The Value of Real Data
For better or worse, I’m a baseball fan. It’s something I grew up with. My grandparents were devout Detroit Tigers fans. Some of my fondest memories are of listening to the game on the radio with grandparents and extended family.
One of the talking points in baseball circles these days is the pace of the game. It was a recent topic when the Red Sox and Yankees took nearly 5 hours to play a game last month. There are a few generally accepted reasons why some of the games take longer than others. Most people passionately describe the time consumed when the catcher goes to the mound to talk to the pitcher and the amount of time consumed by the pitcher between pitches. In fact, MLB has instituted new rules this year that are supposed to govern some of these times.
A funny thing happened recently in the midst of all of this discussion. A baseball writer (Didn’t write down his name…) sat down with video of several notoriously long games and measured times. He used a stop watch to measure the amount of time taken for each individual activity. With absolute times in hand, he was able to clearly tell precisely where time was consumed. The activities that took most of the time were not those generally accepted to be the culprits. It turned out, for example, that Derek Jeter stepping out of the batter’s box and walking around between pitches consumed a lot more time than any of the pitchers or visits to the mound by a catcher.
Why bore you with all the baseball reference? It’s an example from my personal frame of reference that illustrates an aspect of the human condition that affects the management of IT infrastructure. It’s really easy to accept that something is factual when one or more individuals speak with passion that it is so. That system is slow because the java app is using too much memory, or it’s slow because the database is over extended. It’s all too easy to accept. I’ve done it. We had a recent performance issue with our back-end servers. Our entire development team, myself included, was convinced that the issue stemmed from the aggregation of data. We all just accepted that as reality because it made a lot of sense. It was logical. However, when we looked at the visualization of the applications on our infrastructure, it was very clear very quickly that we were all wrong. Data aggregation was really consuming less than 5% of CPU resources. It was the act of responding to API requests that were consuming up to 30% of CPU.
The point is; get the facts. Easier said than done, I know. You don’t have access to the real facts if you are looking at server resources alone – they are insufficient to see the detail you need. Transaction times alone aren’t going to fully inform. All of the copious information that you can get from individual components is a patchwork of data, much of it contradictory. The information from byte code insertion tools is detailed, but it doesn’t help much with management of your application infrastructure. Maybe if you wrote much of the code yourself, you can get what you need. Either way, it’s like real work to get what you need.
What you need is a consistent view of the apps running on your infrastructure. A view that is the same for all apps; web server, app server, database, Java, .Net, Ruby, PHP…well, you get the idea. If you are managing infrastructure, do you care which line of code is calling a SQL statement? Do you care if you’re dealing with Java or Ruby? You do care about the performance profile, about what resources the apps require, about bottlenecks. So, why not look at what matters to you?
Give it a try – it’s easy and not at all scary: http://appfirst.com/sandbox/
Tags: Donn
This entry was posted on Thursday, May 13th, 2010 at 1:10 am and is filed under Company News. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
