Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!inquo!in-news.erinet.com!bug.rahul.net!rahul.net!a2i!dhesi.a2i!dhesi
From: Rahul Dhesi <dhesi@rahul.net>
Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.bsd.bsdi.misc
Subject: Re: Tuning BSD as Web Server (was Re: Unix too slow for a Web server?)
Date: 21 Sep 1996 17:40:52 GMT
Organization: a2i network
Lines: 66
Message-ID: <5219b4$552@bug.rahul.net>
References: <323ED0BD.222CA97F@pobox.com> <jimhill.843028011@kitsune> <51pbm6$97o@web.ddp.state.me.us> <32404E4A.41C6@phoenix.net> <51rsu5$6je@flash.noc.best.net> <WINDLEY.96Sep20085157@margay.cs.byu.edu>
NNTP-Posting-Host: waltz.rahul.net
NNTP-Posting-User: dhesi
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:27696 comp.unix.bsd.bsdi.misc:4935
> Matthew> I got bad news for you then... BEST is using a challenge L
> Matthew> for serving it's user pages, and it appears to max out at
> Matthew> around 70 hits/sec. There are just too many bottlenecks in
> Matthew> the kernel....
>I'm convinced (by my gut) that BSD (free or not) can support large numbers
>of hits on a web server only with some fine tuning. The same is probably
>true of the web server as well (Aliasing is done, for example, using a
>linear search---thus slowing down *every* hit).
The following saved posting may be of interest.
== begin saved posting ==
Date: 30 Nov 1995 10:43:00 GMT
From: Rahul Dhesi <dhesi>
Newsgroups: ba.internet
Message-Id: <49k1rk$4ph@hustle.rahul.net>
Subject: Re: Best.com
Re machine loads, after dealing with various UNIX machines for a long
time, I have come to the conclusion that all common versions of UNIX
have built-in limits that it is unwise to exceed. Such limits are not
well-documented. They exist because of two reasons:
1. Kernel debugging is done under certain conditions. Loads much higher
then these conditions will trigger bugs that were never triggered during
beta-testing.
There are numerous such bugs. The wise machine user will
stay within load limits that won't trigger these bugs.
2. Many data structures use sequential searches. Beyond certain
load thresholds the kernel spends too much time doing such
searches. Robust kernels will use better search strategies for many
data structures. BUT THERE IS ALWAYS SOME LINKED LIST SOMEWHERE
THAT WILL BE LINEARLY TRAVERSED, because the OS designers assumed
that the list will never grow so much that the search becomes too
slow. And often a loop-within-a-loop in the kernel will
traverse multiple lists, yielding O(n**2) behavior.
Do not make such lists grow too much.
The rapid increase in the processing power of hardware can mislead you thus:
X machine has R SpecINTs and handles N users.
Y machine has S SpecINTs so obviously it will handle N*2 users.
It doesn't work that way! More processing power simply means that the
same number of processes will run much faster. It doesn't mean you can
put more processes, or more open file descriptors, or more active
TCP/IP sessions, or a greater number or sockets in which you are doing
select(), on the machine.
Simplifying outrageously, we state:
The number of simultaneous distinct activies that can be
performed on a machine varies as the square root of its procesing power.
Need ten times as many processes? Better get a 100-fold faster machine.
--
Rahul Dhesi <dhesi@rahul.net>
"please ignore Dhesi" -- Mark Crispin <mrc@CAC.Washington.EDU>
== end saved posting ==
--
Rahul Dhesi <dhesi@rahul.net>
"please ignore Dhesi" -- Mark Crispin <mrc@CAC.Washington.EDU>