The cost of each tier in a web application increases as you move from URL to SQL. From the white paper:
“In the first tierthe Web tierthe cost of serving static content by use of commodity boxes running Apache is very low and, due to its stateless nature, very predictable.
In the second tierthe J2EE tierthe cost of hardware may be the same, but both the infrastructure software and the custom application logic are significantly more expensive.
The result is predictable: Applications that tend to allow each request to get past the first or second tier will be much more expensive to scale, and applications that rely on data access from the database for each request will encounter severe limits on their scalable performance.
The lesson learned is this: handle the incoming load in the earliest-possible tier, and do it with resources that have predictable scale-out behavior and costs. For most applications, those are the resources represented by commodity hardwareservers with fast CPUs and plenty of memory.
Also, you should deliberately build an architecture that will bottleneck in the earliest-possible tier on either the CPU or in memory. Why? Youre going to have a bottleneck, whether you choose to or not. And if you dont pick the bottleneck deliberately, its going to end up in the most expensive and difficult-to-scale part of your environment.”