load balancing - code considerations?

sneakyimp

I am about to start a new project and my client has expressed the desire that the code be ready for a clustering/load balancing server configuratio at some stage.

I found a cool link on the concept here:
http://talks.php.net/show/clustering-tropics/0

What I'm wondering is are there any special things I should do in my code to anticipate a loading balancing server setup with multiple machines?

It seems like it will be pretty easy for me to set up several servers running my php code base with each pointing to a single dedicated data server running mysql. just make the database connect to www.xxx.yyy.zzz rather than localhost:

$link = mysql_connect('www.xxx.yyy.zzz', 'mysql_user', 'mysql_password');

Might there be other considerations? For instance, for handling sessions via database. I've heard that using 'files' as a session handler can result in performance problems when your server's hard drive is racing back and forth to fetch first this tiny file and then that.

On the other hand, in a cluster config where one machine is handling database duties, seems to me that the server might get really bogged down if each and every page access requires a database query.

Anyways, if anyone has any advice or anecdotes or links, I'd LOVE to see them. Got any horror stories? Any hard-won knowledge or tips would be quite helpful.

MarkR

Obviously everything will depend on your exact setup. Talk to your sysadmin and get them to prepare a test cluster, or if that's too expensive, describe how the system would behave in the desired cluster configuration.

If you have a single database server, it is typical for all the web app servers to use it, yes.

In any case your application should be configurable as to which database it connects to.

If you've got a cluster which doesn't have single-system-image (they typically don't), then using files for session storage won't work (unless it's on a shared filesystem). Ask your sysadmin whether they'd prefer you to put your sessions on a shared filesystem or in the database.

Mark

sneakyimp

Thanks Mark. You're always there for me!

Given that i'm starting a new project, I'd kind of like to give the impression I know what I'm doing. There is no need at all for clustering in the short term. I'm thinking it will be at least a year before we even talk about clustering configurations. I understand a little about them from that link I posted above, but I'm still a bit confused. Rather than having to rewrite my whole project later, I'd like to set it up now so that it's well-prepared for a load-balancing setup later.

To that end, I plan to encapsulate all the database interface functions in a database class. I also plan to encapsulate all the session handling functions in a session class. That way, all database intensive code will be at least separate from the main body of code and I can rewrite at a single vantage point rather than scouring all the code for database references.

QUESTION 1:
In a clustered server setup where we have several dedicated mySQL servers replicating a single database, we apprently need to route all INSERT and UPDATE queries to a single machine. Do I need to do this in my PHP project or can the mySQL machines be smart enough to do it?

As for load balancing strategies, I noticed several variants and I believe I understand the pros/cons of each. however...

QUESTION 2:
How do you find the bottleneck in your system? Seems that before we even go to a clustered system it might make sense to just upgrade the machine from a single disk to RAID or add more RAM or get two processors.

MarkR

sneakyimp wrote:
QUESTION 1:
In a clustered server setup where we have several dedicated mySQL servers replicating a single database, we apprently need to route all INSERT and UPDATE queries to a single machine. Do I need to do this in my PHP project or can the mySQL machines be smart enough to do it?

That depends on your implementation system for the cluster. If you use a NDB cluster, these behave as a single server, hence no special effort is required in the application. If correctly configured, in the event of the failure of one server, the other is used automatically, and when the first comes back they resync.

I'm not an expert on MySQL clustering, I just happen to know someone who is.

The traditional model of a single replication master and several slaves improves cluster performance but still creates a single point of failure. The NDB clusters (apparently) avoid this.

QUESTION 2:
How do you find the bottleneck in your system? Seems that before we even go to a clustered system it might make sense to just upgrade the machine from a single disk to RAID or add more RAM or get two processors.

You are thinking of using a cluster for performance. This is normally bad. Clusters generally perform much worse than a single machine - the only advantages being that they're more scalable and have redundancy.

Using a cluster for redundancy is an honourable goal but you still need to be sure that there is no single point of failure (if you want to do it properly).

I can't answer this question - you're going to have to use your own tools (from the OS, maybe PHP profilers etc).

In my opinion wrapping all these database and session functions in a "class" is pointless if you do it before you need it.

In particular, PHP already has a pluggable session handling interface, there's no need to duplicate it.

Mark

sneakyimp

thanks for the really helpful info.

my point about the classes was that i can put my rinky-dink, non-clustered code in there for now and continue on the rest of the project hopefully without needing to concern myself with the inner working of the db setup, for instance. since i'll be using a class, i'll have a single point where i can alter the behavior of all queries throughout my entire project (even switch dbase technologies).

i'm trying also to use classes for error reporting and logging, sessions, and mail so that i can just go to the class if clustering has some impact on the functionality. these areas all seem to have some system/server specific aspects to them.

i'm not sure if i said it before, but the likelihood of needing clustering is pretty low at the moment, but the client has made it clear that they don't want to suffer from performance problems should the traffic demand experience any significant growth. i just want to be ready.

gonna google around for 'load testing' related topics.