Red Hat, Speed, and a Web server (fwd)

[rhofland at fastdial.net (Randall Hofland)]

A couple of questions and comments:

"James R. Van Zandt" wrote:

> Jesse Noller <jnoller at allaire.com> writes:
> >I have to build the fastest Linux web server I humanly can.
>
>   I guess the first thing I would set up is enough diagnostics to tell
>   what the bottleneck is.  /proc/loadavg tells part of the story.  Maybe
>   /proc/stat and /proc/net/netstat too.  Not sure how to interpret
>   those.  Anything else?
>
>   I suppose the communications hardware is likely to be the bottleneck
>   for a system serving a WAN.  If you're on a LAN, you can install one
>   or more fiber optic NICs, I suppose.

How about starting with an FX backbone for the switches and perhaps
limiting FX NICs to serve a only the most powerful of SMP servers? Surely
clusters of modest SMP servers bound by 100TX to the switches and then a
1000GX backbone would be adequate and more cost effective?

>
>
>   Failing that, I expect disk to be the next bottleneck.  UW SCSI with
>   enough disks to fill the available bandwidth, in RAID 0 or RAID 5
>   configuration.  If forced to use IDE disks, at least put only one on
>   each bus, and try enabling DMA.  Mount the disks read-only.  (Well,
>   you didn't say what the job was :-)

I now doubt that the onboard ATA/100 RAID solutions are as fast as they
should be for server needs although certainly adequate for very modest
requirements. The AMI RAID chipset is the only onboard unit that I know of
to actually claim (still!) that the RAID is supported in Linux. I am also
assured by SuSE that it (AMI) does works under Linux. So I am planning on
buying one of those 3Ware ATA/100 RAID cards (when I can afford it) which
now support RAID 0, 1, 1+0 and 5, AND also have dedicated connectors for
each drive to maximize throughput (available in 2, 4 and 8 drive versions).
I will also be testing out one of the Iwill boards with that AMI onboard
RAID capability

ATA/100 remains the most cost effective solution but I'd sure like to know
just how fast some of these options really are! SCSI certainly has some
advantages but remains limited to some extent by the shared bus nature of
SCSI. Mutli-channel UW3/160 sounds wonderful but remains much more costly
than adding several 3Ware 4-port boards (although I believe they also are
limited to 32bit/33MHz transfers unlike some of the higher end UW3
options). Still, there is a growing trend in Linux and perhaps even in
Windoze systems to utilyze ATA/100 RAID solutions unless the budget
encourages otherwise. And I will argue that is will be some months, perhaps
even years before money again flows freely in IT.

>
>
>   In the unlikely event that the processor turns out to be the
>   bottleneck (fractal image compression on the fly? :-) then use an SMP
>   motherboard.
>
> Come to think of it, I'm not sure what the point is.  After Microsoft
> trumpeted their benchmark results, somebody pointed out that a quite
> modest machine can fill up a T1 line.  If communications is not the
> limit, then for their job (serving up fixed pages) the simple solution
> is to replicate the database on as many machines as needed to
> satisfy the demand.  Maybe you can give us enough more information to
> clarify why this is a one-processor job.
>
>             - Jim Van Zandt

SMP Athlons are just a few months away now, possibly as early as late April
or early May although I lean towards mid summer before they are widely
available. Tyan supposedly is now taking orders for one with two
64bit/66MHz PCI slots and designed for 1U servers, costing around $1K for
the bare board (but the Athlons will likely remain more cost effective than
Pentiums). New databus and memory technologies as well as much faster
processors will make saturating even cable modems or high end DSL lines
much easier. Perhaps an argument for the GX NICs although several smaller
and more cost effective servers might still preclude such needs as noted
above.

>
> -
> Subcription/unsubscription/info requests: send e-mail with
> "subscribe", "unsubscribe", or "info" on the first line of the
> message body to discuss-request at blu.org (Subject line is ignored).

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).