From owner-freebsd-questions Thu Jul 17 23:57:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA04466 for questions-outgoing; Thu, 17 Jul 1997 23:57:59 -0700 (PDT) Received: from gdi.uoregon.edu (cisco-ts10-line14.uoregon.edu [128.223.150.112]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA04461 for ; Thu, 17 Jul 1997 23:57:55 -0700 (PDT) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.8.5) with SMTP id XAA00415; Thu, 17 Jul 1997 23:57:46 -0700 (PDT) Date: Thu, 17 Jul 1997 23:57:45 -0700 (PDT) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: spork cc: questions@FreeBSD.ORG Subject: Re: ccd under 2.2-stable In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 17 Jul 1997, spork wrote: > I have a machine with two 2G Seagates set up as /home for a colo > web-hosting customer. I've had it with all the 4G drive failures, so I > though ccd would be a nice alternative, just use two fast 2 gigs... > > My question is this; in searching throught the mail archives, there is > alot of discussion about interleaves on a news machine, but I'm curious if > there are any suggestions on what to do if the ccd array will be used for > web-hosting. The array will be doing reads 99.9% of the time, and most > files are either 5-7K jpgs or larger 25-40K jpgs. > > Does anyone have any suggestions on how to optimize ccd for this > application? (BTW, no, it's not porn, it's fashion and we've been taking a > beating w/80M/minute after the Versace murder)... I don't think any optimization is necessary. You can tune it to the news server standard and it shouldn't hurt you. Your big wins are going to come from: 1. Lots of memory so the buffer cache helps you out. 2. Lots of bus bandwidth, so make sure you pick a machine with a 66MHz bus speed (100,133,166,200..) 3. A big pipe to the outside world, never hurts :) Considering the amount of static data you're throwing around, I would think you'd want to go after cache performance. Web accesses (probably) see a lot of temporal locality, so cached repeated accesses that save you the disk access in the first place will give you big wins. If you wanted to, you could probably split up your web heirarchy manually across the disks and still get a performance boost, depending on where you put what. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major Spam routed to /dev/null by Procmail | Death to Cyberpromo