In part 4-2, I talked about the two main starting configuration sub-baselines; one that is based on benchmark tests of the various layers of the solution stack and one that is based on existing production performance characteristics. In this post, I will continue discussing the performance environment configuration baseline.

Once the initial configuration baseline is selected based on the previous two approaches (benchmark tests or production configuration baseline), we could make another set of configuration changes to the initial configuration baseline before starting the performance tests. The purpose of this set of configuration changes is laid out in the following two sections. This set of configuration changes is not possible without a deep understanding of the solution you are trying to tune. Of particular interest here are the resources that the solution is using. I am not talking about only the traditional physical resources such as CPU, memory, disk IO, and network IO. Rather, I am also talking about other resources that are often buried deep inside the solution stack. For approaches on understanding the solution, please visit the following set of blog posts: Is your production environment resilient?

Minimize the number of performance test iterations

This is an awesome goal that the stake holders love to hear. The idea here is to identify all the resources and identify all the corresponding parameters that can be set in a way to allow the performance goals to be met. Anyone who has ever been involved in performance testing will immediately say: this is much easier said than done. The reason for this difficulty is that the solution performance behavior is not fully understood before performance testing starts. So, the exercise, here, is to anticipate/guess the solution performance behavior as much as possible. If these changes meet the performance goals 100%, then that will be the best scenario as there will be no need to make any more iterative performance related changes. If these changes get us closer to the performance target, then we cut down on the number of iterative changes.

Maximize performance

Here, we want to be able to push the performance test environment to the max so that it gets us closer to the performance target. If the initial set of configuration changes enables the solution to meet the performance target, that’s an awesome news to the solution stake holders. If not, then, the iterative performance tuning process starts.

In the next blog post, I will discuss the initial set of configuration changes and give examples.