You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Randy Terbush <ra...@zyzzyva.com> on 1997/07/08 05:28:15 UTC

JPL's rocketing webservers

Seems that memory goes along way toward meeting the demand. They 
have gone from dribbling out ~400,000/day to ~3,000,000/day on each 
of 2 servers.

------- Forwarded Message

WIth 768 servers, I'm seeing a few spare servers.  I think
we may have hit the bulls eye.  Here's the results of a recent
mod_status

for www-a:
Current Time: Mon Jul 7 19:48:08 1997 
Restart Time: Mon Jul 7 18:28:33 1997 
Server uptime: 1 hour 19 minutes 35 seconds
Total accesses: 162894 - Total Traffic: 2.6 GB
CPU Usage: u56.99 s72.86 cu1.92 cs1.67 - 2.79% CPU load
34.1 requests/sec - 0.6 MB/second - 16.8 kB/request
501 requests currently being processed, 24 idle servers 

for www-b:
Current Time: Mon Jul 7 19:47:58 1997 
Restart Time: Mon Jul 7 18:28:21 1997 
Server uptime: 1 hour 19 minutes 37 seconds
Total accesses: 165232 - Total Traffic: 2.7 GB
CPU Usage: u53.78 s74.3 cu3.87 cs2.93 - 2.82% CPU load
34.6 requests/sec - 0.6 MB/second - 17.2 kB/request
506 requests currently being processed, 46 idle servers 

------- End of Forwarded Message



Re: JPL's rocketing webservers

Posted by Brian Behlendorf <br...@organic.com>.
At 08:49 PM 7/7/97 -0700, sameer wrote:
>Which is of course a big MT plus. with MT won't need so much RAM.

Perhaps not a huge amount, as Dean has been arguing.  What OS is JPL's
servers running?  I'd guess Irix since that's what SGI's press release told
me :)

They did turn off hostnamelookups, right? 

And parsing for .htaccess files?

And unloaded any modules they didn't need?

When we tuned the server on the largest site we ever hosted, stripping out
the non-essential modules (i.e. mod_cgi, mod_dir!) we were able to handle
300-400 simultaneous children on a 128MB DEC Alpha 233mhz running OSF/1,
and hitting bursts of 80-100 hits/sec with a sustained average around 60-65
hits/sec.  We still didn't sufficiently satisfy the demand in my opinion
(the accept() queue took 10-15 seconds to get through) but the point is
that there might be a lot more tuning possible.

	Brian



--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Why not?" - TL           brian@organic.com - hyperreal.org - apache.org