*BSD News Article 78816


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>