Posttesting Implementation

By now, you probably have had enough of preparation and testing, and are ready to get started making things better. The following sections look at what to do next.

Recording Your Results

After the hard work of designing and conducting your tests, you should take the time to commit your results to paper. This is true even in the unfortunate and unlikely circumstance of complete failure. Why is this so important?

• Future testing Even if you eliminated all performance problems, the odds are that you will someday need to decipher additional issues for new or altered systems. By documenting your efforts during this round, you can significantly reduce the amount of preparation for the next time you're faced with these kinds of challenges.

• Essential feedback You asked your management, users, and peers for assistance before you began your research. It's important that you let them know what you learned especially if you're still mystified by the performance problems. You don't need to write a 700-page novel to summarize your findings; a one- or two-page write-up will demonstrate your thoroughness and professionalism, as well as earn you good will for future testing. And if you don't summarize things and achieve closure, everyone will wonder what you actually did.

• Helping new hires With turnover rates high, there's a good chance that you'll soon be called on to mentor new employees or contractors. Well-documented test plans and result reports will reduce the amount of time you need to spend educating your new peers.

Making Improvements

Many developers or analysts emerge from their testing with the confidence to make numerous performance-enhancing changes. However, in their eagerness to solve these problems, they often implement too many alterations at once, without allowing adequate time between the modifications. This can easily result in bugs, data integrity problems, and even degraded performance. Instead of rushing into potentially irreversible modifications, take the time to weigh the possible consequences of these amendments.

Generally, it's best to first implement the simplest corrections, such as engine parameter modifications. Should something go wrong, you can always switch back to the parameters' original values. If these first changes improve things, you can then move on to more complex changes, including those that affect SQL, application code, operating system, and database structure. Continue with your measured approach to alterations, and you will end up with a stable, better-performing solution.