“I didn’t have time to write a short letter, so I wrote a long one instead.” –Mark Twain.

When we interact with software, we require it does what we want it to and that it responds to our wishes quickly. The domain of software performance is all about understanding where the time goes when we ask software to do something. Another way to look at software performance is to think of it as a scientific attempt to identify and remove anything that might slow it down.

Let’s consider an analogy. I can travel from Boston to New York City by car in under four hours. I will spend some of my time actually getting to the highway and once there then navigating traffic. Some things that might slow me down include: Stopping for tolls and pausing for a snack along the way. I can prevent such “bottlenecks” by using an automatic toll collection device and packing food and drinks to consume on the way.

Software itself isn’t completely responsible for its performance. We live in a world of interconnectedness where the performance of any modern application is determined by the intersection and combination of multiple systems or influences. The fastest software will not perform well if its environment is not optimized.

Considering my intrastate trip again, even if I have the fastest car imaginable, other factors that might make my trip longer include: The parking brake is engaged for the entire trip; I take local roads instead of the highway; or, I make my journey the day before Thanksgiving (traditionally the busiest travel day of the year in the United States).

Thinking about software again, some non-product aspects in the deployment environment which can influence software performance include:

• Hardware
• Operating System
• Network
• Storage
• Database
• Virtualization

Other systems and/or influences:

• Location of other required services such as licensing, security, user administration
• Resource contention with other applications
• Human users
• Processes or jobs that run regularly

And in some cases, just like our driving analogy, we might need to consider:

• Time-of-day
• Weather

Here at IBM we’re committed to creating the best performing software we can. As in the analogy above, we want to create the best performing car for your needs. However, sometimes software performance problems have nothing to do with the software itself. Many times I have worked with very smart customers only to discover what was thought to be slow software was really not a product problem. These can be very tricky problems to solve, to separate software behavior from the surrounding environment.

Folks who have worked with me before to understand software performance in a complex configuration may have heard me ask, “Where are you getting your licenses from?” Some software products maintain their licenses locally where the user interacts with the software. Other applications request a license from a license server and the few seconds it takes to retrieve this license might appear as a slower login. I have seen customers try a new software release on a test machine and observe slow login performance and become upset. In some cases this is a phantom problem because the test server is far from the license server and network latency will slow license retrieval. Well-designed deployments co-locate application and license servers whenever possible (of course there are valid situations where this isn’t possible).

In optimizing an environment for performance or even when attempting to diagnose a particularly intractable performance problem it is important to understand how the software fits within its environment. Optimal performance requires continual study of many dimensions. One first step is to be sure the environment is well described. This may mean the environment and configuration is documented in slides, reports or drawings. Of course you can use a tool like Rational System Architect, but sometimes a whiteboard will do just as well.

In this well-described environment it’s also crucial to have monitoring in place to alert if something changes, whether it be an unexpected operating system patch needing to be installed or a warning to alert in case a server fails. The best performing environments also are highly available with disaster recovery plans in place and continuously tested. The well-described environment also has simple baselines so that average response times are understood:

Task A takes approximately B seconds under C load at D time of day on E configuration.

Ideally the well-described environment also extends to a matched test or staging environment, and there are active plans to keep the environment up to date with patches, upgrades and other routine maintenance.

I recall working with a customer who couldn’t understand why their freshly updated product would intermittently behave very slowly when it had performed just fine in their test environment. The application logs held few clues, but some of the webserver logs revealed the answer. They had staged the upgrade on a server and then moved that server into production. Completely unintentionally, they had forgotten to remove that server from a list of test servers that could be used for validating load balancing. As a result they had accidentally been putting themselves under a denial-of-services attack. Perhaps a fully described environment might have prevented this problem.

When we think about software performance, it’s easy to forget about all the other factors that contribute to software behavior. Folks on the Jazz and CLM teams think a lot about performance as it relates to applications and environments. In upcoming articles and blogs from the Rational Performance Engineering team and friends, we hope to share and discuss a wide variety of performance topics, especially as they relate to Jazz and CLM.

• We’ll talk about how to define and measure performance. This is a topic everyone has an opinion about, but it’s actually pretty tricky because humans are inherently bad at measuring time: Yes, we can use stopwatches and computers to measure duration, but absent tools, how many of us know exactly when 10 seconds is up?
• We’ll look at different Internet browsers — everyone wants to have the fastest Internet experience possible, and we’ll talk about some of our favorite tools for measuring browser performance.
• We’ll also talk about defining workflows. Articulating software performance behavior involves not just measuring response times but also involves articulating how the software is actually used.
• We’ll also talk about the perils and benefits of virtualization, a pervasive newcomer to the environment which software can live in.
• And we’ll also talk specifically about work the Rational Performance Engineering team is doing with Jazz and CLM. Very shortly, we’ll be posting a JazzMon tool that we describe in the library.

Thanks,

Grant Chu Covell
Sr. Dev. Manager, Rational Performance Engineering
gcovell@us.ibm.com