<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>RE: phasing out Solaris/Oracle/Netscape with Linux/PostgreSQL/Apa che</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Mark Hahn [<A HREF="mailto:hahn@coffee.psychology.mcmaster.ca">mailto:hahn@coffee.psychology.mcmaster.ca</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Saturday, February 10, 2001 5:28 PM</FONT>
<BR><FONT SIZE=2>> To: Schilling, Richard</FONT>
<BR><FONT SIZE=2>> Cc: linux-elitists@zgp.org; pigdog-l@bearfountain.com;</FONT>
<BR><FONT SIZE=2>> beowulf@beowulf.org</FONT>
<BR><FONT SIZE=2>> Subject: RE: phasing out Solaris/Oracle/Netscape with</FONT>
<BR><FONT SIZE=2>> Linux/PostgreSQL/Apa che</FONT>
</P>
<P><FONT SIZE=2>[snip]</FONT>
</P>
<P><FONT SIZE=2>> > SCSI is GREAT, and you should set up redundant hot swaps so </FONT>
<BR><FONT SIZE=2>> if you crash,</FONT>
<BR><FONT SIZE=2>> > you insert a new disk, type "boot", and you're back online </FONT>
<BR><FONT SIZE=2>> with a node. I</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> uh, that misses the whole point of raid, which is to survive hard disk</FONT>
<BR><FONT SIZE=2>> failures. "survive" as in "not crash, keep functioning". raid1 or 5</FONT>
<BR><FONT SIZE=2>> built on IDE disks do this *just*fine*.</FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
<P><FONT SIZE=2>Actually, I'm not just thinking of a single disk crash, but total recovery from a previously</FONT>
<BR><FONT SIZE=2>known, stable backup. Hard to beat a five minute restart time.</FONT>
</P>
<P><FONT SIZE=2>RAID is a great way to go if you anticipate no catestrophic failures.</FONT>
<BR><FONT SIZE=2>A complete rebuild, for example in the event your cluster is connected to the</FONT>
<BR><FONT SIZE=2>outside and someone manages to hack it - or if an innocent scientist works too late</FONT>
<BR><FONT SIZE=2>and runs </FONT>
</P>
<P> <FONT SIZE=2>rm -fR </FONT>
</P>
<P><FONT SIZE=2>on the wrong directory, or if your software vendor dials in and screws up.</FONT>
<BR><FONT SIZE=2>At least you get up and running and buy time to deal with the </FONT>
<BR><FONT SIZE=2>major problem later. It's real important in health care because we can't have down times.</FONT>
</P>
<P><FONT SIZE=2>Hey, it happens. . . .</FONT>
</P>
<P><FONT SIZE=2>> > think Sun stations outperform the Intel boards on disk </FONT>
<BR><FONT SIZE=2>> throughput, but you</FONT>
<BR><FONT SIZE=2>> > could check.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> disk performance is basically no longer an issue: even the cheapest</FONT>
<BR><FONT SIZE=2>> modern disks sustain 20-30 MB/s. if you're concerned with seek times,</FONT>
<BR><FONT SIZE=2>> you simply use lots of spindles. I'm sure there _are_ people who need</FONT>
<BR><FONT SIZE=2>> more than the 90 MB/s that a simple raid of ide disks can sustain,</FONT>
<BR><FONT SIZE=2>> but that's a pretty exotic market...</FONT>
</P>
<P><FONT SIZE=2>There's actually quite a few of them/us. Health insurance companies, banks, </FONT>
<BR><FONT SIZE=2>etc . . . Every second counts when you do $2m per day in transactions.</FONT>
</P>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > You'll take a big performace hit running perl too much - </FONT>
<BR><FONT SIZE=2>> it's interpreted.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> nonsense. perl is compiled, and also not a major performance hit.</FONT>
<BR><FONT SIZE=2>> I just tested a trivial CGI-type perl script, and on my cheesy,</FONT>
<BR><FONT SIZE=2>> so-low-end-you-can't-even-buy-it-anymore machine (duron/600),</FONT>
<BR><FONT SIZE=2>> it takes 6 ms to run. golly gee, I could only do 1.5e6 hits/day...</FONT>
</P>
<BR>
<P><FONT SIZE=2>I'll double check the mechanics of the Perl VM. That I know of, Perl scripts</FONT>
<BR><FONT SIZE=2>are not usually compiled to an object file then linked. </FONT>
<BR><FONT SIZE=2>Not that it's not fast, but with interpretation, there's always overhead.</FONT>
</P>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> you can also imbed a perl VM in your webserver (mod_perl in apache).</FONT>
</P>
<P><FONT SIZE=2>When mod_perl runs the Perl scripts, it's interpreting them.</FONT>
</P>
<P><FONT SIZE=2>> hell, most of that 6ms is actually the (libc) dynamic linker:</FONT>
<BR><FONT SIZE=2>> simply statically linking perl would result in a huge speedup,</FONT>
<BR><FONT SIZE=2>> if you really need thousands of cgi's per second. (for proof,</FONT>
<BR><FONT SIZE=2>> on the aforementioned cheesy desktop, "hello world" takes 8ms</FONT>
<BR><FONT SIZE=2>> dynamically linked, but .4ms statically linked.)</FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
<P><FONT SIZE=2>There you go!</FONT>
</P>
<P><FONT SIZE=2>--Richard</FONT>
</P>
</BODY>
</HTML>