I just wanted to know how this could help me. At the moment I'm running a fairly popular site (with 700+ people online most of the time)

However, the servers have been crashing more and more lately, and I know I'll have to upgrade, and buy more soon.

At the moment I have it running one server for apache, and one for the MySQL server.

Would I purchase two servers for apache, and one for mysql, or two for each, or would it pool them all together...?

As you can see, I'm new to this.

A partner and myself just got a 5 server cluster - 4 Apache and 1 MySQL. The 4 web servers serve php and image content and the MySQL server does just that - serves MySQL data via the private switch.

If you go with two or more MySQL servers for redundency you will need to use MySQL NDB Cluster, and the ndbcluster storage engine. I've tried it before and met with more problems than I expected. The ndbcluster storage engine isn't very great for constantly updating content such as forums. I'd say as long as the MySQL server is a powerful one, it should be able to handle load pretty well and be pretty reliable.

My MySQL server is pretty powerful, I'm not sure what the problem is with my site at the moment, but I'm fairly sure it has to do with Apache.

I've also tried MySQL clustering before, and I also was met with a few... problems. Which is something my site couldn't afford because it's an online game, and people are making transactions every second.

Also - would you suggest using the WHM load balancing, or a real load balancer from theplanet?

Have you thought about moving to lighttpd?

I agree with Blue, if you have a powerful Mysql server, then 1 is fine. A real load balancer would be better, though obviously more costly.

What kind of load averages are you getting?
Have you tweaked the settings?

WHM load balancing is far from load balancing. I wouldn't trust it at all. Go with a real physical load balancer. I have used the Foundry ServerIron series load balancers several times and love them. They're very reliable and have a high throughput with low onboard CPU usage. I don't know what kind of lb hardware TP has, but I know at ev1 they have the ServerIrons.

While we might be able to provide general rules of thumb for someone looking to cluster, no one here can truly answer your question.

You'll need to do some profiling and find out where your bottleneck is. Enlist some administrators familiar with this sort of thing, if needed. Also, sometimes web applications can't just be split up and have work, depending on whether they do any database caching, and whatnot (consult your programmers)

Scaling applications beyond a single server can sometimes be more of a challenge than just hooking up more hardware, since sometimes that doesn't always work. A high transaction game where everyone's actions need to be immediately visible by everyone else, and it starts to get tricky. That's why even Blizzard has problems with servers getting overloaded. If it was as simple as just plugging in a few more servers, they woulda done it.

For example, clustering a database is fine, but will this really save you much time? If every action involves a database update, then all you're doing is propogating each update to both servers and duplicating the work. That doesn't save you any time at all, and incurrs replicational overhead.

So what's the next step, then? Breaking up your data into chunks that can be handed off to a discrete server. Like myspace assigns each user a "home" database and home webserver. Like how secondlife breaks down each zone and hands it off to a dedicated server. Their applications don't work against a single colossus database because it's pro grammatically infeasible.