Good quotes from Oracle "Unlimited Application Scalability" whitepaper
The cost of each tier in a web application increases as you move from URL to SQL. From the white paper:
"In the first tier—the Web tier—the 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 tier—the J2EE tier—the 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 hardware—servers 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? You’re going to have a bottleneck, whether you choose to or not. And if you don’t pick the bottleneck deliberately, it’s going to end up in the most expensive and difficult-to-scale part of your environment."
"In the first tier—the Web tier—the 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 tier—the J2EE tier—the 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 hardware—servers 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? You’re going to have a bottleneck, whether you choose to or not. And if you don’t pick the bottleneck deliberately, it’s going to end up in the most expensive and difficult-to-scale part of your environment."