Date: Mon, 18 Feb 2002 01:23:28 -0800 From: Alfred Perlstein <bright@mu.org> To: Anthony Atkielski <anthony@freebie.atkielski.com> Cc: FreeBSD Questions <freebsd-questions@FreeBSD.ORG> Subject: Re: in-kernel HTTP Server for FreeBSD? Message-ID: <20020218092328.GU12136@elvis.mu.org> In-Reply-To: <002d01c1b85a$12a6e720$0a00000a@atkielski.com> References: <20020217143343.41758.qmail@web21104.mail.yahoo.com> <20020217173609.A25030@energyhq.homeip.net> <3C703154.91ED7FB4@mindspring.com> <20020217224724.GL12136@elvis.mu.org> <018c01c1b816$6482f5a0$0a00000a@atkielski.com> <20020218022759.GM12136@elvis.mu.org> <002d01c1b85a$12a6e720$0a00000a@atkielski.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Anthony Atkielski <anthony@freebie.atkielski.com> [020218 00:55] wrote: > Alfred writes: > > > More hardware means more sysadmin time, means > > higher chances of failure, means your software > > must be more robust in dealing with failures. > > No. A system with 1 GB requires no more maintenance and is no less stable > than a system with 256 MB. A system with a 1300 MHz processor is no less > stable and requires no more maintenance than a system with a 200 MHz > processor. Yes but so far time travel hasn't been invented. Read on... > > > An example is a large server farm that I know > > of that even with true ECC ram gets several > > non-recoverable memory errors per-day. > > Reduce the number of servers, and make them larger. That may help. Yes, throwing out several hundred boxes and replacing them certainly sounds cost effective to me. :) > > Expenses go up the larger your cluster is ... > > Who said anything about expanding a cluster? > > > No amount of hardware thrown at a problem can > > equal a well thought out design. > > Any system that must be dedicated in order to use 100% of the machine for > application load is underpowered. Production systems must have safety > margins in capacity if there is any variance in load at all. There were plenty of cycles available once my server was in production. Those numbers were just me benching it on what was pretty much the fastest equipment available at the time! By the time we started seeing it max out the system, newer chips were becoming available which when deployed reduced the system's load. At 450mhz I was doing 5000/sec, you _just couldn't do that_ with apache or pretty much anything else available on the market at the time (when 450mhz was the only thing reasonably priced), in fact apache couldn't do more than several hundred per-second with what was available at the time. You simply can't throw tomorrow's hardware at today's problems because it just doesn't exist. :) Your only choice of hardware to throw then becomes throwing in equal machines into clustering clustering "solution" which will only scale properly when done properly. Again, case in point, Ebay's problems a couple of years back when they maxed out the e10k. They maxed out the cpus in the poor thing and then had to take a nice long downtime in order to really archetect out a solution. When I needed to do to the back-end database system I needed to spread the customer load amongst them in order keep them from falling over, this was accomplished via course grained load balancing of customer accounts, not simply throwing more CPUs into a single box which sort of stops working at 4 or maybe 8 with intel "hardware". A lot of work was also thrown into a system to improve upon the performance of just doing plain database updates. So please don't preach to me about scaling systems, chances are unless I'm actually asking you for help I don't need your advice. Telling me to just throw in a larger CPU doesn't do me much good when my intention is to utilize the fastest currently available hardware to its fullest potential. :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020218092328.GU12136>