The PHP Scalability Myth
Subject:   Two-tier vs. three-tier
Date:   2003-10-17 12:39:26
From:   anonymous2
Response to: Two-tier vs. three-tier

Physically separating the tiers is more hurtful than helpful. If your web server and application are both sharing the same hardware, and your application needs more power but your web server doesn't, how will it hurt anything to simply run the combination on more servers? It won't. But it will cut down on the overhead of communicating with remote servers, which is very significant.

The only thing that matters is being able to run the CPU-bound section (or whatever the bottleneck is) on more hardware. The fact that the web server is now getting more power than it needs is not a problem.

Full Threads Oldest First

Showing messages 1 through 3 of 3.

  • Two-tier vs. three-tier
    2003-10-17 12:53:13  anonymous2 [View]

    It hurts things in several ways:

    1) It means you now have to load balance across more web servers, which means you need more IP addresses mapped to your DNS entry (assuming you don't have a hardware-based web load balancer, which are expensive), which means changing your DNS entry every time you need more horsepower, which gets to be a pain to maintain.

    2) You now have more webservers to maintain, rather than N webservers (N constant), and many more "generic" application machines. If you've every tried to maintain more than 10 webservers at a time, you'll realize this is a royal pain.

    3) If you have a DMZ (which you probably do if you're in an enterprise situation), you don't really want your machines running your business logic in the DMZ (after all, we all know a DMZ is untrusted, right?). You especially don't want to multiply the number of DMZ machines because you're not getting the performance you need.

    4) The assumption here is that the business logic is fairly non-trivial, i.e., that the hit you take from the network hop is trivial compared to the performance increase you get from being able to amortize the load across N machines.

    5) It's MUCH easier to load balance back-end machines than webservers, simply because the discovery process for the webserver is DNS, whereas you can use something like a location service to find machines in the backend that can service your request. Even better, this means that you can add machines ON THE FLY in the backend without your front-end presence having to change at all. It's truly plug-and-play.

    Folks, this is the reason for three-tiered architecture. Believe it or not, people didn't just make it up to sell more machines. It's a real solution to a real problem - how do you scale an application where the display processing is relatively trivial, but the business logic is where most of the processing occurs.
    • Two-tier vs. three-tier
      2003-10-17 20:09:46  tarrant [View]

      Sorry, but I couldn't imagine anyone using DNS-based load-balancing when you can do it with Squid sitting in front of the webservers, or better yet set up a hardware load balancer like Big/IP. With DNS round-robin, you get the round-robin, but you don't get any kind of protection against machine failure.

      Your assumption on (4) isn't valid either, in my experience. How long does a page normally take to respond, in your experience? If it takes more than 0.5 seconds, then you're going to start getting antsy; more than 2 seconds and you're really going to get agitated. Meanwhile, for that 2 seconds of calculation, you've still got 8-30 seconds of image and css downloading, depending on your modem speed. Now, it's true that most of the CPU time in total is either biz logic or database, but on a 0.5s page you can't afford the latency involved in marshaling a request, sending it over the LAN, unmarshaling the request, marshaling the response, sending that over the LAN, unmarshaling the response, and repeating all of that for each remote method call. It's too much overhead.

      I don't know about you, but I've got 6 years of solid experience specifically architecting, building and maintaining high-traffic e-com sites. Sites with 1K-20K visitors per hour. And my experience is that presentation should be separated logically from business logic, but should not be physically separated. I believe there should be a "3-tier architecture", but tier-1 is a caching/proxy layer, tier-2 is presentation+bizlogic (i.e. the webserver), and tier-3 is the db:

      loadbalancer <--> cache/squid <--> apache/tomcat/whatever <--> database

      It's the architecture that's always worked best for me, and no matter what the starting point is on a new project, we always seem to gravitate to this solution. The cache/squid layer caches stuff like images, but it also buffers connections, allowing the webserver to get freed up faster when some guy's downloading a big page on a 9600bps modem.
    • Two-tier vs. three-tier
      2003-10-17 17:28:59  anonymous2 [View]

      which means changing your DNS entry every time you need more horsepower, which gets to be a pain to maintain.

      ? Yeah, yahoo adds dns entries everytime they add a webserver. This is nonsense.