ISTEK Consulting - Performance Tuning Concepts

Overview
The two hardest things to know about performance tuning is when you should start, and when you should stop. Some have said that premature optimization is the root of all evil. I don't really agree with this statement. Like in many other pursuits, there are certain key drivers in performance tuning, where 20 percent of the effort can yield you 80 percent of the gain. Lets look at some of them here.

Where do I begin...
Disclaimer: Most of my experience in performance tuning has been in N-tier business applications, therefore I will tailor these pages to describing the issues commonly faced by these types of applications. Most of the concepts, however, can be applied to a variety of applications.

As I mentioned before, knowing when to start performance tuning is key. You need to start thinking about performance when you design the system. If this is not done in the inception phase of the process, changing the system may mean rewriting most of it or accepting the fact that at some point it cannot perform any better. One thing to consider is that many times people will say "This app will never need to perform" for whatever reason, and then to everyone's surprise, the app starts pushing more and more volume and the performance characteristics of the system become critical.

So what does it mean to design a system for performance? Here are some parameters to consider.

Is the primary requirement of the system good throughput or response? If you are concerned with throughput, you may be able to trade off response time for an ability to scale horizontally, i.e. running multiple parallel processes. The ability to scale horizontally then will become a critical aspect of your design.

If response time is the highest priority then you need to look at tuning I/O. Unless you are writing one of the rare apps that is CPU intensive(CPU tuning strategies here), chances are good that you'll be spending most of your time there. In apps that use a database, this means you need to design a reasonable compromise between the cleanest design in code and the way the code invokes the SQL. This is an easy thing to say and a harder thing to do, but basically where people run into problems is ignoring the concerns of the database folks while designing their application. There is especially a high level of mistrust between Object Oriented developers and DBAs (most of it warranted on both sides).

More performance tuning concepts...

Overview	The two hardest things to know about performance tuning is when you should start, and when you should stop. Some have said that premature optimization is the root of all evil. I don't really agree with this statement. Like in many other pursuits, there are certain key drivers in performance tuning, where 20 percent of the effort can yield you 80 percent of the gain. Lets look at some of them here.
Where do I begin...	Disclaimer: Most of my experience in performance tuning has been in N-tier business applications, therefore I will tailor these pages to describing the issues commonly faced by these types of applications. Most of the concepts, however, can be applied to a variety of applications. As I mentioned before, knowing when to start performance tuning is key. You need to start thinking about performance when you design the system. If this is not done in the inception phase of the process, changing the system may mean rewriting most of it or accepting the fact that at some point it cannot perform any better. One thing to consider is that many times people will say "This app will never need to perform" for whatever reason, and then to everyone's surprise, the app starts pushing more and more volume and the performance characteristics of the system become critical. So what does it mean to design a system for performance? Here are some parameters to consider. Is the primary requirement of the system good throughput or response? If you are concerned with throughput, you may be able to trade off response time for an ability to scale horizontally, i.e. running multiple parallel processes. The ability to scale horizontally then will become a critical aspect of your design. If response time is the highest priority then you need to look at tuning I/O. Unless you are writing one of the rare apps that is CPU intensive(CPU tuning strategies here), chances are good that you'll be spending most of your time there. In apps that use a database, this means you need to design a reasonable compromise between the cleanest design in code and the way the code invokes the SQL. This is an easy thing to say and a harder thing to do, but basically where people run into problems is ignoring the concerns of the database folks while designing their application. There is especially a high level of mistrust between Object Oriented developers and DBAs (most of it warranted on both sides).
More performance tuning concepts...