Date: Tue, 26 Oct 1999 23:04:03 -0700 From: Mike Smith <mike@smith.net.au> To: Ben Schumacher <bs@cyalchemy.com> Cc: freebsd-hardware@FreeBSD.org Subject: Re: FreeBSD Server Hardware Configuration Question. Message-ID: <199910270604.XAA00634@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 26 Oct 1999 18:48:56 MDT." <4.2.0.58.19991026182732.00989a80@mail.cyalchemy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I am working on a project in my company where we will need to be able to > handle large amounts of traffic on a web server we are setting > up. Basically, we estimate about 75,000 visitors a day with roughly five > 20k page views each, which makes roughly 7.5GB of data a day. Most of the > pages we'll be offering on this site are static, but access to the site > will be need to be verified through a database of say 750,000 customers. This is not "large amounts of traffic"; you should be able to do all of this on a single, fairly small system. > I guess what I really need is a good idea of what is necessary to make > these machines powerful and responsive. I think the best solution for the > web server would be a powerful P3 Xeon server, using a hardware RAID system > with at least 1GB of RAM. This would be outrageous overkill. A mid-sized P-II system with a moderate amount of memory (128-256M) should be able to cover all of your page-serving requirements. You should obviously benchmark your implementation, and you'll want to design for peak capacity so you will need to know the likely access patterns for your userbase. But even so, you're talking about less than 0.5M hits a day, which is really loafing. Figure that 75,000 visitors a day averages out to about one every second or so. If they all visit you inside a two-hour period, you'll have to authenticate about ten a second; that's probably a reasonable peak performace figure. You'll want to design your database carefully to keep its performance requirements down; it's not that this is a difficult task, but it's very easy to get database design wrong. You might want to design a custom authentication application for this purpose; do the math for a moment. Assume you allow 16 characters for the username, and 16 more for the authentication token. 32 * 750,000 is a mere 24M to hold the entire database in memory. If you index it aggressively, you'd still be hard-pressed to use more than 32M for the entire process. > The database server, on the other hand, I'm a > little more unsure about. I haven't had enough experience with MySQL to > know what keeps to running fast and smooth. I figure that it probably > relies heavily on drive speed and RAM, but how important are issues like > having a large L2 cache on the processor? For this application; more or less irrelevant. > One last thing. We're looking at getting the server equipment from one of > the big vendors (Dell, Micron, etc), but while searching the archives that > Del''s PERC RAID controller is not support (or was not) by FreeBSD, any > world on when/if it will be? I know that Micron's is support (since Walnut > Creek uses it). What are some other hardware RAID solutions available and > from which vendors could I get them from? Actually, WCarchive uses a Mylex SCSI:SCSI controller (as far as I can tell, Micron don't actually make RAID controllers). I've been working on drivers for a number of the PCI:SCSI RAID controllers (including the PERC and PERC 2/SC), but they're not really ready for general usage yet. Without meaning to rain on your parade here however, it doesn't look like you actually need a "big vendor" solution, nor RAID, nor a 1GB Xeon, nor even two machines to more than admirably handle your application. Buy an economical, compact PII or PIII box from someone nice like Telenet, put a 9GB IBM SCSI drive in it, and make the occasional backup so that if the drive dies (unlikely) you can bring it back up. If you're really paranoid, build two machines and have the second mirror the first. You could even splurge on something like Polyserve's product and run a 2-node redundant cluster and _still_ save money. The cardinal rule, as always, for systems design at this stage: know your requirements, and specify the hardware accordingly. Don't go shopping for what you want to need; you'll either screw yourself by trying too hard to save money, or screw yourself by wasting your money on hardware you'll never need or use. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910270604.XAA00634>