Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!cancer.vividnet.com!hunter.premier.net!news-peer.gsl.net!news.gsl.net!news.sgi.com!news.msfc.nasa.gov!newsfeed.internetmci.com!news.kei.com!news.texas.net!news1.best.com!nntp1.best.com!flash.noc.best.net!not-for-mail
From: dillon@best.com (Matthew Dillon)
Newsgroups: comp.os.linux.misc,comp.unix.bsd.freebsd.misc,comp.infosystems.www.misc
Subject: Re: Unix too slow for a Web server?
Date: 25 Sep 1996 01:22:29 -0700
Organization: Best Internet Communications, Inc. (info@best.com)
Lines: 66
Distribution: world
Message-ID: <52aq45$9ka@flash.noc.best.net>
References: <323ED0BD.222CA97F@pobox.com> <R.1996Sep21.083306.26626@indyvax.iupui.edu>
NNTP-Posting-Host: flash.noc.best.net
Xref: euryale.cc.adfa.oz.au comp.os.linux.misc:131491 comp.unix.bsd.freebsd.misc:27917 comp.infosystems.www.misc:44061
:In article <R.1996Sep21.083306.26626@indyvax.iupui.edu>,
:Mark H. Wood <mwood@indyvax.iupui.edu> wrote:
:>Reposting article removed by rogue canceller.
:>
:>In article <323ED0BD.222CA97F@pobox.com>, Subhas Roy <subhas@pobox.com> writes:
:>> A ZDnet article says in the web page
:>> http://www.zdnet.com/pccomp/features/fea1096/sub4.html#jump2
:>> that Windows NT-based servers run much faster (as much as 13
:>> times) when client counts are low.
:>>
:>> Is that possible? Anybody wants to comment on the
:>> article's claim?
:>
:>Where to begin?
:>
:>1) Something Else must be going on. This is the same sort of jive that
:> Unix vendors used to pull on other OSes. The CPU clock doesn't tick
:> faster just because you have one OS or another. Of course Unix had
:> that big I/O block cache, and the others didn't (then).
:>
:>2) Is the difference really significant? If one server responds in 13
:> nanoseconds and another in only one, do humans (who respond in seconds
:> to milliseconds) really care?
:>
:>3) How do the results scale with load? I mean, do we really care about
:> unloaded performance? Most people are more interested in how response
:> varies when load nears capacity (and it seems that Web servers are
:> *always* running near or over capacity!)-: .
:>--
:>Mark H. Wood, Lead Systems Programmer +1 317 274 0749 [@disclaimer@]
:>Internet: MWOOD@INDYVAX.IUPUI.EDU BITNET: MWOOD@INDYVAX
:>Trapped in a world he never made.
Yes, there can be a huge difference across different OS's running on the
same CPU. Some operating systems, such as NT, have so many layers that
to do a particular function can take twice as long (or worse!) then
operating systems that provide a less layered interface to the program.
Latency and overhead is key, because while the difference between
1 microsecond and 3 microseconds may not seem to be much, it turns
out to be quite significant when you scale up and wind up running
the function a couple hundred thousand times a second. The little
overheads build up when you scale up.
This why UNIX will almost certainly always beat NT when it comes to doing
anything that needs to be scaled up. Short of rewriting NT, there is a
limit to the efficiency achievable for certain critical elements of the
system such as network and filesystem access, and multitasking overhead.
Another critical area, as you have mentioned, is in buffer/page management.
Unix just doesn't have "that big I/O block cache". It isn't as simple as
that... what Unix has is a (usually) integrated VM/paging system that
allows both user programs and the kernel itself to access network and
filesystem elements with virtually *no* buffer copying and very little
setup/tear-down overhead. It took the UNIX folks a long time to realize
that even with a super-fast cpu, the difference between having to copy a
block of data (possibly multiple times), and not having to copy the
data can gain you a significant advantage... sometimes as much as
several hundred percent in a heavily used resource.
-Matt
--
Matthew Dillon Engineering, BEST Internet Communications, Inc.
<dillon@best.net>
[always include a portion of the original email in any response!]