Dedicated Servers + Scalable Web Architectures

[Christopher Browne]

On Mon, Jun 23, 2008 at 3:02 PM, Marc Lanctot <lanctot-yfeSBMgouQgsA/PxXw9srA at public.gmane.org> wrote:
> 2. I'd like a recommendation on an architecture or *good* book on this
> subject, or even better pointer to scientific studies which compare
> different architectures in practical experiments. I'm very familiar with the
> Apache/MySQL/PHP setup so that is my current preference -- as long as it can
> scale! I'd be happy using Tomcat/JSP/Servlets if it means it means better
> scalability in the end. People have told me that Ruby on Rails doesn't
> scale-- after playing with it a bit two years ago it doesn't seem hard to
> believe, but it was still more of a superficial investigation than anything
> else.

Part of where you need to start is by determining just what you think
you mean by "scalability."
<http://en.wikipedia.org/wiki/Scalability>

Formally, it indicates that a system has the capability to either
handle growing amounts of work in a graceful manner, or generally to
be readily enlarged.

At the simplest level, it might be considered to indicate something
like "if traffic doubles, can I cope with that by doubling the
size/number of servers?"

But when you're thinking about it, you should be looking for
characteristics that allow you to do "better than linear" scaling.
When thinking of algorithms, the *good* ones are the ones that exhibit
logarithmic scaling, rather than linear scaling; those are the ones
where you can scale by orders of magnitude without difficulty.

Keep in mind that this does not simply apply to the software; it also
applies to the administration and operation of the system.  You don't
want doubling the number of servers to require hiring twice as many
sysadmins, for instance.  Or for doubling the number of customers to
require doubling the number of administrative staff.

Database systems tend to "scale with difficulty" in comparison with
certain other classes of systems; you can frequently scale DNS or web
applications simply by adding extra servers, but, eventually, throwing
hardware at databases has limits.  Here's a pretty good discussion of
database scaling <http://www.boic.com/scalability.htm> which isn't
platform or DBMS-specific.

One pretty good book on "scalable architecture" is _Scalable Internet
Architectures_, by Theo Schlossnagle.  It has some pretty useful
perspectives on the matter.

An interesting web site that takes a different twist on this is this
one:  <http://www.kegel.com/c10k.html>  It addresses the issue of how
you can think about building internet services that can handle 10000
concurrent connections (that's what "C10K" stands for).  It tries to
present "brute force" resolutions to the issue.

One of the major abstractions for supporting scalability is that of
message queueing.  This allows grouping requests together so that they
may be processed efficiently, in some bulk.  That it splits processing
out into asynchronous portions is a big win, too.  That tends to be
good for the application...
-- 
http://linuxfinances.info/info/linuxdistributions.html
"The definition of insanity is doing the same thing over and over and
expecting different results." -- assortedly attributed to Albert
Einstein, Benjamin Franklin, Rita Mae Brown, and Rudyard Kipling
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists