[consulting] Drupal server requirements

[Darrel O'Pry]

On Wed, 2006-03-29 at 15:49 -0800, Michael Haggerty wrote:
> > -----Original Message-----
> > From: John Handelaar [mailto:john at userfrenzy.com] 
> > Sent: Wednesday, March 29, 2006 1:19 PM
> > To: mhaggerty at trellon.com; A list for Drupal consultants and 
> > Drupal service/hosting providers
> > Subject: Re: [consulting] Drupal server requirements
> > 


> > Meanwhile, as I tell anyone who asks me directly, the first 
> > step is usually to throw memory at any performance issues, 
> > the second is to physically seperate the DB from the web 
> > server, and only when that stops working do we get into clustering...
> 
> Well, yeah, that's probably what most people advise. But when you have a few
> dozen sites, it's a little nicer to be able to just toss everything into the
> cluster and not worry about scaling. Considering how cheap it is to set up
> and maintain a cluster, why take everyone through the same path? Couldn't
> the cost to maintain the cluster be amoritized over a few of the bigger
> sites and save each new client some money? As the pool of clients grows, so
> could the cluster, reducing everyone's utilization of resources.
> 
> > ...by which time, I have no doubt, the read/write split in 
> > Drupal will be solid and existent.
> 
> Unsure what this is really going to accomplish. I mean, the point here is to
> scale what happens at the database level.
> 
> How is Drupal going to know where to write the data when you have 2 write
> servers? Obviously, you don't want to do all commits to a single database or
> you could end up with a massive bottleneck that is worse than not segmenting
> operations in the first place. Outside of writing a separate module to
> determine where the activity is being directed, wouldn't something like this
> effectively limit the platform to a single write database?
> 
> For that matter, isn't traffic control exactly what a cluster is supposed to
> do? Why is this effort being duplicated?

1) Mysql nor Postgresql are cluster aware. In terms of parallel
computing clusters like beowulf. 

2) Mysql only supports a naive,  Single master, many slave clustering,
except for NDB which is a main memory only DB, and would probably lack
the storage capacity for sufficiently large sites. 

Ingres has some interesting distributed functioning which would allow
you to do interesting things like to node, user, and statistical data on
different hosts with different Database applications.

There is always Oracle 10g RAC...  (also relies on a caching
architecture)

IBM's DB2 is apparently cluster aware on their own clustering platform.
...................

There there is always system level performance tuning on you server....
Many people speak of Adding more RAM... You can also look at solid state
drives if your budget supports it... RamSan being at the top of the
market with a 15-20K entry price, but more realistic for most drupal db
servers would be Gigabyte's i-ram whose 4GB capacity is rather limiting,
but great for mail queue on busy mail servers. Raid 0 is a possibility,
but was unstable when I was playing with them last.  There is also
another upcoming DDRdrive(ddrdrive.com)  that is a PCIe solution and is
said to support up to 8GB of storage. And of course there is the
HyperDrive's from the guys at hyperOS that starts around 1K.