[PLUG] What do y'all want in your servers?

[Ronald Chmara]

On Feb 8, 2006, at 8:46 AM, AthlonRob wrote:
> Ronald Chmara wrote:
>> On Feb 6, 2006, at 9:28 AM, Jeff Schwaber wrote:
>>> Would you rather 10-20G IDE drives or 4-9G SCSI drives?
>> Is that 10x20G drives (200Gb) or 4x9 (36Gb total)? Either way, I'd 
>> take
>> SCSI, myself.
> I think you're being optimistic.  :-)

Possibly. :-) Since RAID was mentioned I assumed there was at least 2 
drives. ;-)

>>> Would you rather pay a little extra and have RAID (probably software)
>>> installed on the system when you get it?
>> Software RAID: Hell no. Hardware RAID: Yes.
> Have you looked at Software RAID ever or are you just assuming it 
> sucks?

I've used it on various platforms over the years, and while I've had 
numerous problems with different software RAID setups, I haven't had 
the same level of problems with hardware RAID. In addition, by putting 
hardware RAID on a different physical controller, the CPU/mobo can 
offload more work (thus needing less CPU/mobo power).

>  Seriously, give it a shot - its performance is excellent and it can 
> add
> additional flexibility not found in inexpensive hardware RAID (true
> hardware RAID) setups.

Any specific recommendations on current software RAID (closed or open 
source, I don't care) that you've found reliable? I may simply have 
been burned by the first few generations of buggy code.

>>> What's your bottom end processor you'd consider?
>> 200 Mhz , nobody beyond the top 200 sites needs much more CPU (or 
>> better
>> programing, but this is a different discussion though)
> You obviously haven't been in web development long.  :-)

LOL, only long enough to have built some pretty intense sites on 200Mhz 
boxes (because that's what was the *fastest* X86 box on the market at 
one time, geez, way to make me feel old)... about 9 years, total. Why 
did I just know I should be expecting further discussion on this topic? 
;-)

> When you start getting in to database-backed sites, especially ones
> doing complicated things, you start eating up CPU cycles like candy.

How one builds such sites *definitely* affects how the CPU cycles get 
used, no?  Most of my sites have rather heavy db backends, but then 
again, I'm also the kind of programmer who both counts *every* db and 
file hit taken per page, and profiles all of my SQL (and other data 
fetching) for optimal query speeds and engines (I've been known to 
combine 2 openldap calls, 2 bdb hits, and 3 PostgreSQL queries on one 
page to maximize speed). I've actually done quite a few rewrites to 
reduce speeds on brutal pages from 10-12 CPU seconds (bleagh!) per page 
fetch to <.02 seconds on the same hardware, just by ripping out 
redundant/un-needed code routines and sub-optimal db access.

By the same token, I've also seen some.... interesting... sites where 
every page load has 20-30(!) db hits to handle user and system 
variables, then 40-50(!) file hits to load up functions/modules/classes 
(etc.), another 50-100(!) db hits to generate actual page content, and 
then another chunk of CPU cycles to simply assemble it all... into a 
mere 25-50K page. Sadly, this kind of page programming seems to be the 
norm for many folks right now (whose law is it that "programming 
expands to fill the CPU cycles available"?)

Worst example I saw ran over 1 million (really) SQL queries per page 
load, and then ran 35 queries based on each result, just to populate a 
page with a subset of the ~1 million items a page *could* be 
displaying.... it went from a 4 hour script (per page generated!) to 
under 3 seconds per page once I was done with it. Sadly, I'm not making 
this up.

And of course, how one *thinks* about distributing tasks over boxes 
also makes a difference. I tend to balance out tasks across multiple 
boxen, for redundancy. I also tend to prefer custom-written software, 
as generic F/OSS software often tends to spend lots of CPU cycles on 
things most of my clients don't need.

> 200MHz just isn't enough juice for the complexity of pages and number 
> of
> visitors I get on my small-time server.  Try running a MediaWiki site
> that gets a few thousand hits an hour on a 200MHz box and get back to
> me.  :-)

MediaWiki? Ah, well..... MediaWiki does not have the best of 
optimizations applied, which is why it can barely manage a page per 
second on slowish hardware (and why squid is taking the brunt of the 
load for wikipedia, 18 squids for 93 apache/PHP boxen). It (MediaWiki) 
wasn't written as a web page program so much as a program which outputs 
web pages... and that's not always the fastest way to write dynamic PHP 
pages. :-)

>> Form factor. Rack units count for small sites.
> Definitely - we couldn't afford more than 1U.
>> RAM capacity and cost.
> More RAM the better... a GB doesn't go as far as it used to.

Oh, and dual NIC's would be really nice....

-Bop
--
Ronin Professional Consulting LLC
4245 NE Alberta Ct.
Portland, OR 97218
678-492-1046/503-282-1370