in reply to Re^2: LAMP svrs - 1 or 2 is best ?
in thread LAMP svrs - 1 or 2 is best ?

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?"

Replies are listed 'Best First'.
Re^4: LAMP svrs - 1 or 2 is best ?
by j_c (Novice) on May 10, 2005 at 14:52 UTC
    so do you have some stats for comparison between using 1 and n servers ? in terms of performance? would I be able to serve 1000 users at 20 secs per page, or 100 users at 1 second per page ? If I buy a car I like to know how much better it is going to perform than my current one, I already know it will cost me more to run because it's a bigger car...

      Sorry you are being confusing now, you are switching from questions of availability to performance and back again. With a database (unless the engine has been specifically designed to work like this) you are unlikely to get any performance increase from adding any more servers above the first one that is running that database, indeed it is simply going to add more administrative overhead. Adding processors (and memory) to a single server is far more likely to reward you with a performance increase (as long as your OS and RDBMS support SMP).

      /J\

      I once took over an application that was running on a 2-CPU webserver w/4GB RAM going against a 4-CPU DB server with 8GB RAM running a tuned Oracle database with a real DBA administering it. It was dog-slow, like 4 minutes a page. I rewrote it to go against an untuned MySQL database I randomly threw together running on a hyperthreaded single-cpu desktop w/2GB that was also running the webserver and some other stuff. Every page returned under 5 seconds, most under 2 seconds. We noticed zero improvement when we split the database onto its own server-class machine. In other words, the number and quality of servers make very little difference if the application is crap and may do little to improve performance for a well-written application.

      As for performance reasons to split your stuff - do it only when your single machine is IO-bound.


      • 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?"