You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by gr...@apache.org on 2002/10/22 17:30:36 UTC

httpd restart on daedalus and more redirects

I've redirected more content to nagoya due to our recent performance problems on
daedalus.  Namely, jakarta.apache.org/builds/jakarta-tomcat-40/release,
jakarta.apache.org/builds/jakarta-ant/release, and the three most popular httpd
source tarballs under www.apache.org/dist/httpd/ (httpd-2.0.43.tar.gz,
httpd-2.0.43-win32-src.zip, and apache_1.3.27.tar.gz).  I chose these URLs
because they were responsible for eating a lot of bandwidth on Oct 20.  I did
this via a non-graceful restart because an httpd buglet wouldn't allow us to
raise the number of httpd child processes.  

Now daedalus response is a lot better, but nagoya seems a little slow.  If this
keeps up, I will un-redirect a few URLs via graceful restart.  Pier, how do
things look to you on nagoya?

Greg

Re: httpd restart on daedalus and more redirects

Posted by Pier Fumagalli <pi...@betaversion.org>.
"gregames@apache.org" <gr...@apache.org> wrote:

> I've redirected more content to nagoya due to our recent performance problems
> on
> daedalus.  Namely, jakarta.apache.org/builds/jakarta-tomcat-40/release,
> jakarta.apache.org/builds/jakarta-ant/release, and the three most popular
> httpd
> source tarballs under www.apache.org/dist/httpd/ (httpd-2.0.43.tar.gz,
> httpd-2.0.43-win32-src.zip, and apache_1.3.27.tar.gz).  I chose these URLs
> because they were responsible for eating a lot of bandwidth on Oct 20.  I did
> this via a non-graceful restart because an httpd buglet wouldn't allow us to
> raise the number of httpd child processes.
> 
> Now daedalus response is a lot better, but nagoya seems a little slow.  If
> this
> keeps up, I will un-redirect a few URLs via graceful restart.  Pier, how do
> things look to you on nagoya?

Things on nagoya do not look good at all... I mean, the uptime is low, but
for some wicked random reason, it maxes out the bandwidth on the
interface.... I don't get it... It looks like everything is going allright
over there, but at a certain point it starts loosing packets, as if the
ethernet was saturated...

I don't get it... _really_ don't get it... Unless (but that can't happen
even in my wildest dreams) someone didn't put up a HUB on nagoya instead of
a switch....

It's odd though... If I had a hub over there (10 mbps plain old hub), I
wouldn't be able to even get to the console (tokio.betaversion.org), but
apparently, I can get to the console allright (it's on the same subnet), but
I can't get to nagoya...

Could it be a broken ethernet interface? I don't know, I don't really think
so, as it always performed great... But as soon as someone is down at Sun
I'll have them switch the ethernet over onto the secondary IF just to see if
that's the cause...

When it rains, it pours, they say, ain't it?

    Pier