If that's not an issue, then there's no reason for a normal-sized site with average traffic to use more than 1 server. If you plan on having larger amounts of traffic, then give the one machine more than one name. That way you can easily add more physical machines, but you already have the software treating everything as if it's on different servers.

we are aiming for a high availability cluster. Even though the network stack creates a bottleneck between servers, at 1gbit it should be small, but the benefit is redundancy - a server can fall over and we can continue service on another server. But the rub is - how to quantitively state what performance loss or gain there is in the n-tier setup. I can see that you can increase the number of concurrent users, but at what cost in the slow down across the network between db server and web server.

You do understand that the cost of a high-availability cluster is extremely high. For every 9 you add, you increase the cost 10x. So, if it costs $10,000/year to provide 99% uptime, it will cost $100,000/year to provide 99.9% uptime. And, so on.

Those values don't mean very much, so let's use some useful numbers. There are 86,400 seconds in a day. Assuming exactly 365 days in a year, you have 31_536_000 seconds in a year. 99% uptime means you are allowed to be down for 315_360 seconds. That's 3.65 days, or 1h 41m every week. (If your maintenance window is 2 hours every Sunday night, you just blew 99% uptime.) 99.9% uptime is .365 days, or roughly 8h 45m, downtime. 5-9's, or 99.999%, uptime, means that you're allowed to be unavailable for 315.6 seconds, or 5m 15.6s, in a year. That's maintenance, backup, and everything.

I hope your company plans on making a lot of money with this site cause your administration costs for high-availability are going to be a bitch.

---

• In general, if you think something isn't in Perl, try it out, because it usually is. :-)
• "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"

Performance isn't the issue - it's security. If you have your webserver outside your firewall and your database inside your firewall, then you can regulate exactly who gets access to the database server. It's that simple.

I don't understand how 2 servers is more secure than 1 server, I tend to think it's the opposite, 2 servers means 2x as much chance of errors in configuration, and I don't think having webserver and database on different machines gives you security you can't achieve with one machine (you can firewall a databaseserver on the same machine in the same way as you can firewall it if it's on a different machine).

I think the biggest advantage of having one service per machine is that you can tune them specifically and independently for the service, so add 'more iron' (ie. RAM, CPU,faster disks) if the performance of one of the services is below satisfactory levels.

Update: I see gellyfish has already made the point I make in my last paragraph (see his comments below)

Assume you have a hardware firewall. This means that to cross the FW threshold, you have to be authorized in some fashion or another. The webserver is, generally, put into the DMZ outside this firewall. You're still going to lock down the ports, chroot the webserver and do all that stuff. But, it has to be outside the firewall so that the outside world knows how to get to it.

The DB server is inside the FW. It doesn't have an outside-accessible name. The webserver, because it's physically connected to the FW, has access to the internal DNS, so it knows how to find the DB server.

Basically, it's an additional layer protecting the only thing that's important - the data. You can't just hack the DB server - you have to hack the webserver to hack the DB, and even then, you only have the access the web application has.

---

• In general, if you think something isn't in Perl, try it out, because it usually is. :-)
• "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"

You seem to be confused about the term n-tier - the n is not a function of the number of servers in your hardware architecture but of the design of the application. You already have at the very least a 2-tier architecture in your application in as much as you have a program (probably combining presentation and business logic layers) and a data layer in your RDBMS.

Splitting the separate application tiers onto different servers is not necessarily going to enhance the performance of your application in itself, but will give you a number of opportunities whereby the performance can be increased, say by optimisation for the particular role of the server.

/j\

Multiple machines means you can do failover for higher uptime, and it also means you have literally twice as much power to put into serving your application. There is a cost to the load-balancing, so it won't exactly double your scalability, but it can get close.

It sounds like you're trying to sell your management/boss on some idea. It also sounds like you're not a technical sales type of guy. If the "M" in "LAMP" stood for "Oracle" or "DB2", you could get Oracle or IBM to send out a technical sales critter to convince your boss. ;-) These are the guys whose livelihood is based on producing/selling, among other related things, highly available, highly performing database systems.

The question is, under a reasonable load, how many CPU cycles do you have left? For example, if your average is 10 hits per second, and your peak is 200 hits per second, check what the response times are for these scenarios. Check where most of your performance degredation is: is it in your database or in your CGI scripting? If it's the CGI, then what you want is multiple web servers. If it's the database, then you want a cluster of database servers.

Regardless of whether you stick with MySQL, or you switch to Oracle or DB2, you'll want an experienced professional to babysit your system(s). Or at least to set it up and tweak it, although doing proper backups is pretty key here, too, and that's an ongoing duty. That experienced professional need not be certified, but does need some sort of experience in whatever scale your site is (100MB, 1GB, 10GB, 100GB, 1TB - how much data do you have? And reliability - how many 9's do you need?).

There are just too many variables to say that it would be "better" (what is "better"?) by a factor of X. I suppose I'd start with whether your system is fully (or nearly fully) loaded as it is. If you have disk I/O and CPU cycles to spare, then splitting the two tasks will do nothing for speed. Security, yes, but speed, no.

I'm going to give you a hand and ask you: why do you think 2 servers are better than 1?

Go on, answer me :-)

see above - does that help ?

For this analysis, you need to know what your current MTBF and MTTR for the server and software responsible for service x. Almost nobody actually collects that data before heading down the path you're on now, so you'll have to guess. Assume you guess that the Mean Time Between Failures and the Mean Time To Repair numbers end up giving you an availability of 94% per year. If we further assume that you are able to add an exact replica of that server/service and ignore the additional failure points added by the clustering software/hardware, then to find the new availability just multiply (1-0.94) by (1-0.94) and you get .0036, subtract that from 1 and you get 99.64% availability.

As you split things up, it may get easier to manage, and easier to replicate the various pieces, but all this means you get to complicate the picture more and more, and as the server/service availability gets better, the more you need to ensure the networking parts of all this are equally reliable/available/fault tolerant. Then the supply of power get to be important, etc.

-Scott