Re: Resource estimation

• Mail folder: WWW Talk Apr-Jun 1993 Archives
• Next message: Tim Berners-Lee: "Re: Adobe Acrobat released"
• Previous message: Terry Allen: "RE exotic characters"
• In-reply-to: Tim Berners-Lee: "Re: Resource estimation"

From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: Resource estimation 
In-reply-to: Your message of "Wed, 16 Jun 1993 10:04:22 +0200."
             <9306160804.AA03888@www3.cern.ch> 
Date: Wed, 16 Jun 1993 10:15:36 -0500
Message-id: <8299.740243736@moose.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Thus wrote: Tim Berners-Lee
>>From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
>>For my proposal that's going to the committee here (I'm soon going  
>to
>>make all my CWIS documents available for public review via our WWW
>>server -- I wrote them in HTML so it shouldn't be too hard to serve
>>them :-) I need some estimates of the hardware to run a dedicated  
>WWW
>>server off.
>
>In fact, the load on an HTTP server machine is very slight,
>because the process only runs as long as it takes to return
>the document. The info.cern.ch server which has the Subject
>Catalogue gets probably a relatively high usage, about
>10k requests a day, or (thinks...) one every 9 seconds.
>the CPU load is negligible.  In fact of course the peak rate
>is higher, but still its not really a factor.

This goes along with our experience (though our load is only maybe 40%
of yours.)  Just passing text files along is pretty cheap.

Of course, if you're getting to pick the platform, part of it depends
how you'll have the server configured and what kinds of access it will
be doing.  If you are using standard multithreading with lots of
fork()ing then a system with copy-on-write would be nice.  If your
server does lots of execing instead, this won't help as much.  Lots of
physical memory is always nice (lazy man's performance philosophy is
to let the OS do the caching.)  Being able to plock() the server
process so it doesn't get swapped might be good, though if it's as
heavily used as you hope this won't be an issue much.

Will people be using this system to just fetch simple HTML files, or
as a gateway, or to do frequent queries of large databases?  I expect
that only in the last of these three is adequate CPU power likely to
enter into the picture.  If you anticipate doing cryptographic
manipulations as part of transactions (e.g. kerberos authentication or
PEM or something like that) obviously that can eat some CPU.

- Marc
--
Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted
"I cannot recommend this candidate too highly or say enough good things about
him.  In my opinion you will be lucky to get him to work for you.  I urge you
to waste no time making him an offer.  No one would be better for the job."