phasing out Solaris/Oracle/Netscape with Linux/PostgreSQL/Apa che

[Mark Hahn]

> > do I absolutely, positively need SCSI? I was thinking about putting a
> > second 100 EIDE host adapter in, and run disk striping plus mirroring
> > over 4 EIDE hard drives (the better models from IBM). Or should I
> > use a Dual-Pentium mumboard with onboard SCSI, and buy several fast,
> > hot & noisy scuzzys, soft-RAIDing them? Perhaps even harware RAID?
> > I don't think the disks need to be very large, but they 
> > better be fast.
> 
> SCSI is GREAT, and you should set up redundant hot swaps so if you crash,
> you insert a new disk, type "boot", and you're back online with a node.  I

uh, that misses the whole point of raid, which is to survive hard disk
failures.  "survive" as in "not crash, keep functioning".  raid1 or 5
built on IDE disks do this *just*fine*.

> think Sun stations outperform the Intel boards on disk throughput, but you
> could check.

disk performance is basically no longer an issue: even the cheapest
modern disks sustain 20-30 MB/s.  if you're concerned with seek times,
you simply use lots of spindles.  I'm sure there _are_ people who need
more than the 90 MB/s that a simple raid of ide disks can sustain,
but that's a pretty exotic market...

> You'll take a big performace hit running perl too much - it's interpreted.

nonsense.  perl is compiled, and also not a major performance hit.
I just tested a trivial CGI-type perl script, and on my cheesy,
so-low-end-you-can't-even-buy-it-anymore machine (duron/600),
it takes 6 ms to run.  golly gee, I could only do 1.5e6 hits/day...

you can also imbed a perl VM in your webserver (mod_perl in apache).
hell, most of that 6ms is actually the (libc) dynamic linker:
simply statically linking perl would result in a huge speedup,
if you really need thousands of cgi's per second.  (for proof,
on the aforementioned cheesy desktop, "hello world" takes 8ms
dynamically linked, but .4ms statically linked.)