1. If the response time is improving under increased load, then something is broken

I have never seen a case where a running application sees its response times drop as more load is added, with the rare exception of applications that dynamically add resources (such as server processes) when the load increases.

Algorithms rarely work better under increasing load for a simple reason. Programming projects are notoriously late, and when late, performance optimizations fall by the wayside. So look for errors, or dysfunctional behavior, when things magically get faster under heavy load.

2. Ignore everything to the right of the decimal point

There is always uncertainty in the results generated by performance work. Some meters just sample the data, some count everything, and some start early or late. Reporting results like “37.238” is always a waste of time and usually a bit of a lie.

Report the integer part and ignore the fractional part. If you are so close that the fractional part matters, then you are too close for comfort.

If you have to report the fractional part, show a consistent number of decimal places in all your results.

3. You’ll do this again. Always take time to make things
easier for your future self

In performance work, there is often lots of waiting to do between peaks or while tests are running. I always use some of that waiting time to look for better ways of gathering data, analyzing data, and turning it into presentable information.

Many of the things that can affect performance can be both unlikely and time-consuming to look for, so you tend not to look for them. When I find these things, I figure out a way to check for them and add that to my tool called UnlikelyThings. I let that tool do the hard work for me.

4. Always serve bad news with a side order of possible solutions

There is not a manager on Earth who wants to hear, or reacts well to, unrelenting bad news. When driven into the corner, some will come out swinging and fight you tooth and nail on every depressing detail you have to offer.

Assuming there is some good news to deliver, start with some good news, or at least tell them that there is some good news coming. This relaxes the tension somewhat and makes your job easier.

5. Always tell the truth, but in a kind and helpful way

Never use your performance skills as a basis for saying harsh things about the design or implementation of your computing world. Show your results, identify the problem areas, suggest improvements, but stick to the facts and don’t denigrate individuals or use harsh descriptors such as, “stupid”. People you work with usually built that computing world and they have families.

Harsh words never help, but they can backfire on you. When attacked, people want to protect the job that takes care of their families. They look for ways to stop you, and nobody needs that.

Bob Wescott is the author of “The Every Computer Performance Book”.

Related Links:

More information on this, and many other useful ideas, can be found in Wescott's book:

The Every Computer Performance Book

Bob Wescott, Author of "The Every Computer Performance Book" Joins the BSM Blog