Web Performance Tuning, 2nd Edition

Chapter 3. Capacity Planning

Most processes can be divided into two classes: I/O-bound and CPU-bound. The serving of static HTML is usually I/O-bound. It is limited by the rate at which a file can be retrieved from disk (if not already in memory) and the speed at which the file can be moved out the network interface. Disk and network are I/O devices, far slower than CPU, so CPU power does not play a significant role.

Generation of dynamic HTML is just the opposite. It is usually CPU-bound, meaning that it takes longer to create the page than it does to move the page out the network interface. CPU is critical here, especially if you’re using CGI’s or Java servlets to create your dynamic pages. Most of that CPU processing is string manipulation. On the other hand, dynamic content depending that depends on database queries is usually limited by the speed of the database, which in turn is usually I/O-bound because it needs to retrieve data from disk. So how to plan for capacity depends entirely on how your site works.

Do the Math . . .

When you evaluate a potential architecture, the most critical part of the job is to compare your required latency and bandwidth to the rated capacity of every link in your proposed configuration. Each component should meet those requirements with an additional margin for component interaction inefficiencies and increasing load over the life of the architecture. You could skip the calculations and forecasting, buy something that satisfies your immediate ...