In part 4-3, I described the two main goals of the initial set of configuration changes that you should provide before starting performance testing; the goals are to:

1. Minimize the number of performance test iterations
2. Maximize performance

In this post, I will provide some tips on laying out the initial set of configuration changes.

Use the “funnel” configuration: The configuration in the top layer of a solution stack should look like a funnel as shown in Figure 1. What is important here is that as requests flow into the solution environment from left to right, the requests are queued up when the downstream resource is exhausted. For example, if the JDBC connection pool (far right) is exhausted, the incoming requests will wait to get a connection from the JDBC connection pool. As you can imagine, as more requests keep coming, more requests will wait to get a connection pool. These requests may wait in different locations depending on two conditions:


Figure 1: "Funnel" configuration

1. The downstream resource is exhausted
2. More requests keep coming in

So, requests may wait in front of the JDBC connection pool, EJB container, Web container, and so on. The goals of this funnel configuration are:

1. Protect the downstream system from being overwhelmed by incoming requests
2. Satisfy performance requirements
3. Satisfy resiliency requirements

To determine the various resources of this funnel configuration, a deep understanding of the solution architecture and solution resources is required.

Ensure the configuration is coherent: The configuration may look like a funnel, but may not be coherent. This is best illustrated by an example. For example, assume that each web container thread needs two database connections at the same time to process a request. If that is not taken into account, the JDBC connection pool will be sized less than the web container thread pool based on Figure 1. At low concurrency levels, such an incoherent configuration will do fine. However, as the concurrency level (more active web container threads) increases, a serious performance degradation, including deadlock, can occur. This is because there is a scenario where each web container thread (execution thread) grabs one connection which results in the JDBC connection pool being exhausted. In this case, each web container thread waits endlessly on another JDBC connection which will never come. Here, a deep understanding of the application architecture and implementation becomes even more crucial so that a more coherent configuration is set up.

Document all clients: One or more solution resources may be shared across two or more solutions. Although the other solutions are not the subject of the performance testing in this cycle, it is important to account for them when setting up the configuration. For example, a database is a typical shared resource across many solutions. It is crucial here that the configuration of the database is set up in a way that would support all the various solutions without any performance degradation for any solution.