Date: Sat, 16 Oct 1999 12:58:40 -0700 (PDT) From: Mike Meyer <mwm@phone.net> To: freebsd-smp@freebsd.org Subject: Re: SMP on 4 Pentium III(450NX) failed Message-ID: <Pine.BSF.4.10.9910161240590.31550-100000@guru.phone.net> In-Reply-To: <199910161823.LAA06715@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 16 Oct 1999, Mike Smith wrote: ;->As a general rule, think "more small, cheap machines" rather than "one ;->big expensive machine". This is a strategy that has worked well for ;->many people (yahoo, hotmail, etc.). Yes, indeed. The exceptions are rare, and getting rarer. Even things that are heavily compute bound can benefit from this - see the seti@home project <URL: http://setiathome.ssl.berkeley.edu/ > for an extreme example. The other exception that comes to mind is if you have a large database that needs to stay synchronized, but even then the worst case is a large, fast DB machine behind an array of small, fast web servers. If you can partition the DB, then you can replace that large, fast DB machine with an array of small, fast machines. If your DB is in some sense fuzzy (by which I mean sharing some of the properties of the typical web search engine), then even a DB machine being down is no great loss. Is anyone really going to complain that you missed 1% of the URLs on the web when a larger percentage than that are probably out of date? The headache that comes with it is you have to manage all those systems. I've not found a clean approach yet. Is anyone working on one - or better yet, have one? <mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9910161240590.31550-100000>