Monday, October 22, 2007

So what performance can I expect?

While most days at work are busy with Linux performance analysis and improvement projects, I regularly get questions from customers, or our sales and support teams, plus seekers of information on performance questions. In these discussions, the prevailing quick question is invariably:
  • Say.... "My user has this application running on this system with this software. If we change one or more of these pieces, would the application run much faster?" That's usually the whole question. Then there's the expectant long pause as they wait for "The Response."
The answer of course is always: Well, it depends....

So we start with the two basic questions.
  1. What specifically are you running today?
  2. What are you really trying to improve?
I know it's going to be fun when the the first question turns into a lengthy informational gathering exercise. What system, specifically. What software, specifically. Is the software pre -built? or do you build it yourself? What system configuration, specifically. What are you measuring, specifically. I don't really keep score, but several of these informational requests never come back. I suspect they were looking for the Silver Bullet. It happens.

Assuming we make it past the first information scrub, we begin focusing on what they really want to improve. The choices are quite varied.. usually they just want faster execution time. Sometimes better (quicker) responsiveness. Sometimes there are other considerations, scaling up, scaling out, or server consolidation with various virtualization techniques. Whatever it is, understanding specifically what they are measuring is critical. In the realm of performance, we measure, change one thing, measure again, assess the change. And repeat.

I have observed that occasionally in the realm of some performance engagements, little is known, many things are changed, and conclusions quickly reached. Worse, these conclusions have an almost mystical ability to end up on an executive's desk.

So while we often get involved in helping to select the appropriate hardware platform, the focus in this new blog is where and how Linux can make a difference. These entries are intended to help me keep track of a journey of learning to be a better performance analyst. The three cases to cover are (a) when I think I already have the answer, or (b) more often - having some of the answer and hunting down those pesky details, or (c) in some cases, I really haven't a clue, and I'm off on another learning tangent again. As I said, it's a journey.

There's a lot of cool things happening around the world of Linux performance. In the coming weeks, I'll talk about some of the areas that are active, emerging, or are already in use. Some will be on Power where I spend a lot of time, but a lot is generic and usually available across the platforms. Whether this will help you improve the performance of your applications, well, it depends. We shall see.

No comments:

One of many bloggers.

Bill Buros

Bill leads an IBM Linux performance team in Austin Tx (the only place really to live in Texas). The team is focused on IBM's Power offerings (old, new, and future) working with IBM's Linux Technology Center (the LTC). While the focus is primarily on Power systems, the team also analyzes and improves overall Linux performance for IBM's xSeries products (both Intel and AMD) , driving performance improvements which are both common for Linux and occasionally unique to the hardware offerings.

Performance analysis techniques, tools, and approaches are nicely common across Linux. Having worked for years in performance, there are still daily reminders of how much there is to learn in this space, so in many ways this blog is simply another vehicle in the continuing journey to becoming a more experienced "performance professional". One of several journeys in life.

The Usual Notice

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions, try as I might to influence them.