Deriving good performance is about more than careful design. It may be surprising, but the art of application performance starts when there is not even a single line of code. It all starts with the requirements and the goal of the system.

Below is a short summary of key points for deriving a good design and mitigating performance bottlenecks risks.

1. Ask performance related questions very early. When I meet business people they know what they want, at least from the functional point of view. However, when I ask them about the forecasted number of transactions per second or number of user operations (or any other performance related quality of the system) I rarely hear a reasonable response. It's either unknown or totally trumps up. This is due to the fact, that in many project approaches (waterfall, iterative, etc.) technical people focus on familiar artifacts and business people are left alone. Hardly anyone tries to help them gather cohesive performance requirements. Although it requires effort (as to assume the distribution and characteristics of transactions) there are many techniques that can facilitate the process: 'similar to' approach (select similar system and try to estimate using known number of transactions), 'key business drivers' approach (take the drivers, such as number of customers served, take transaction data from outer source, which can be an alternative, existing channel or business unit operating in similar business environment) and then make the estimation. The point is to emphasize performance issues at the conception phase of the project and to have the aim clearly stated.

2. Crude performance tests are better then no tests at all. Believe it or not, many projects are launched without any performance tests. This is often the case when the new system is designed and no reference points are available. On the other hand, sometimes I face the situation that the system is mature but still there are no tests during major upgrades. It leads to very unpleasant surprises a second after putting the system on the production environment. Thus, don't ever go on production without tests. Under budget and having a comfortable schedule? Try sophisticated and professional tools and services such as Wily, for instance. If that's not the case, use open source tools (there are a variety of possibilities and options here) or hands and heads of Your teammates. As a very last resort just gather performance data and have a serious look at it. Search for the most frequent and the most time consuming operations.

3. Use the force of 20/80 rule. Focus only on important things, such as testing and analyzing application or modules rather then individual classes/components. I recommend using the top down approach to find elements that will give your solution the greatest performance boost. Thus, when assessing performance I'd rather focus on tiers, database connectivity, systems interoperability and interactions as these are mostly the candidates for bottlenecks. Despite the fact that there are some rare situations where the computationally expensive algorithm is the cause of the problems most of cases does require little or no code review and modification.

4. Don't be blind. Provide (buy, reuse or develop) tools that will measure and gather performance related data. Contemporary systems usually span multiple tiers and integrate with many external applications. So You need a probe that can be put into all building blocks of the solution, including the web tier , business tier, integration, database, network and operating system. You should gather data on threads, workers, open connections, errors and warnings, exceptions, latency, trip time, response time, storage, network interfaces, processes, specific system's settings, memory, garbage collection and many others. Gather it, analyze, review and review again. Only then could you see how your application performs. Imagine that I've seen a major system launch which was a disaster due to the specific security settings of the host machines kernel's setting (selinux). Of course, it's generally highly advisable to have a security enhanced operating system. Finally, it's up to you whether to have a professional all in one measuring appliance or just a set of shell commands and systems' logs - the pith of the matter is to have any.

5. Appreciate people, tackle problems. Finding bottlenecks involves cooperation with people, that know the system and connected elements best. These people are often under stress as they are blamed for the problems. Therefore they focus on gathering evidence to protect themselves instead of using their potential to solve the problem. This is the place where you should act as a good therapist - relieve the stress and fear to build motivation and increase commitment. They need to believe that you don't pose a threat to them. Then it's more likely to quickly find the bottleneck as a team.

To sum up, performance related issues are not bound to the code only. They span multiple areas, and what's most important, they involve people. Following the aforementioned guidelines can bring noticeable effects with respect to the performance of the applications you deliver.

Having further questions? Want to comment? Feel free comment and to contact me at grulka@maciejgrula.com.

For PDF version of this article visit my homepage.