Women in Technology

Article:		The PHP Scalability Myth
Subject:		Two-tier vs. three-tier
Date:		2003-10-17 12:12:03
From:		anonymous2
To begin with, the author apparently doesn't understand the reasons behind three-tiered architecture. It has nothing to do with "code factoring". It has to do with scalability. Not performance. Scalability. They are completely different issues, especially in the context of complex business applications. In enterprise applications, it's not good enough that your end-to-end performance be good, it's also important that those machines service requests quickly, which is where a two-tiered architecture fails (and which is why people came up with the idea of a three-tiered architecture in the first place). This is the difference between performance and scalability. For instance, suppose you get a sudden flood of requests coming in. Your webserver might be able to handle the number of incoming connections, but now, since all of the non-DB processing is happening on the same machine, you become CPU-bound, so that, even though the web server can accept more connections, it can't get enough of the CPU to service all of the requests it has. Now, instead, think of a three-tier system. The web server handles the request, and passes off to another server (load balanced on the back end) to do the business processing (we're assuming here that the business processing is substantial compared to the display processing, which is usually the case in an enterprise context). Now, the web server can continue accepting requests up to its networking capacity, but it can offload its business processing onto *multiple* other machines if needs be, so that each request can happen faster, which is what the end user perceives as "better performance". *That's* scalability. And that's what you won't achieve with PHP, or any two-tier based language. Now, if you want to talk about adding hooks to do remote procedure calls to PHP, or some other scripting language so you *can* do three-tier architecture, then we can talk about scalability (at least, scalability for an application that has non-trivial business logic). Otherwise, they are, and will continue to be, inadequate for complex business applications, because they aren't scalable. Period. -- Jack Lund STA Group, LLC

Showing messages 1 through 3 of 3.

• Two-tier vs. three-tier
  2003-12-12 09:11:13  anonymous2 [View]
  
  
  Once a web server accepts an HTTP connection, that connection cannot be "passed off" to another system: it must handle that connection to completion.
  
  Suppose an HTTP connection has been established between the client (e.g., browser) and the web server. That connection must remain open until the same web server generates a response. Also, even though information from the initial request may be is passed to another tier, the result of that information must be returned _back_ through the same web server for final processing before being returned to the client. During that time the web server must maintain all data structures necessary for the
  - HTTP connection, and
  - connection to the next tier (e.g., database connection).
  This is where any scalability limitations apply.
  
  It is better to maintain a redirector _ahead_ of the web servers. The purpose of this component is to redirect the request to the least-loaded web server.

• Two-tier vs. three-tier
  2003-10-17 12:39:26  anonymous2 [View]
  
  
  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.

• Two-tier vs. three-tier
  2003-10-17 12:18:50  anonymous2 [View]
  
  
  A lot of the 'heat' being generated here appears to stem from the absence
  of a good definition for "scalability" in the article. This is a common
  problem.
  
  Scalability is an abstact notion. So are terms like "reliability", and the
  word "performance" itself. One person's meat is another's poison. With
  regard to computer system performance, you might desire to optimize such
  metrics as, throughput, response time, or resource utilization; to name a
  few. The goal depends on the context. If you're printing reports at the end
  of the financial year, MAXIMUM throughput is likely to be your goal. In
  contrast, many web applications focus on MINIMIZING user response time.
  
  Simply put, 'scalability' is a relation among variables (performance
  metrics) that characterizes the rate of diminishing returns as the
  dimensions of the system are increased. This means that scalability can
  actually be expressed in a mathematical form. I've tried to illuminate this
  point elsewhere http://www.perfdynamics.com/papers.html. Specifially,
  http://www.teamquest.com/html/gunther/fitting.shtml and
  http://xxx.lanl.gov/abs/cs.DC/0210017 should be of interest.
  
  --Neil Gunther