You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@organic.com> on 1997/06/12 19:32:31 UTC

list delays

On Thu, 12 Jun 1997, Randy Terbush wrote:
> > Has anyone noticed some real long delays lately in the propagation
> > of the messages on the list?
> 
> Yes. Things looked a bit rocky at organic's front door yesterday.

Here's what I sent to "msgs" on hyperreal yesterday, which supposedly
all hyperreal users read when they log in.  I wanted to keep this
somewhat quiet as I looked for alternatives but they haven't been
cropping up.  Also realize that the Apache project has top priority
when it comes to scaling back services.

Let's get the mirror stuff up asap.  As of this morning Apache traffic
was over half the total HTTP traffic from hyperreal.


####
In an unfortunate reversal of fortune, it has been declared by the
"higher ups" at Organic (I'm not at the top of the pyramid there, it
may surprise folks to know) that bandwidth on Hyperreal is now
officially "too much".  Unchecked, it would be consistantly over 750
kbits/sec, sometimes as high as 1MB/sec, and since Organic's total
potential "quality" throughput (defined as 50% of potential) is only
2-3MB/sec, hyperreal needs to be scaled back until we can get more
bandwidth in here.  In the long term things look very rosy - serious
talk of a T3 abounds - but for the medium term (next 4-5 months) we
will have to endeavor to reduce bandwidth.  Organic would like to see
it reduced to 450-500kbits during the "peak"  hours.  Until we're down
to that, the router at Organic is configured to drop a couple packets
every now and then, in effect rate limiting us to 500kbits/sec or so. 
As a consequence, interactive traffic (telnet and vrave) will feel the
brunt of the problem, as they rely on reliable packet delivery the
most.  If we reduce overall traffic those services should improve. 

Here are the steps I am taking in an attempt to reduce bandwidth:

1) I am doing a thorough analysis using some TCP tools to see exactly
where bandwidth is being consumed.  Initial investigations suggest
mailing list traffic is just as large as web traffic. 

2) After today, Hyperreal will not take on significant new projects
where bandwidth is non-negligible. 

3) I configured the mailing list delivery engine, qmail, to go a lot
slower than normal.  Before, it could allow for 90 simultaneous
transmissions, I've cut that back to 30.  Mailing list mail will take
longer to deliver.  In addition, there may be some other mailing list
policies established to shift traffic to non-peak hours. 

4) The FTP servers have been cut back to 20 simultaneous connections.

5) Apache web traffic will be pushed to mirrors as much as possible.

6) I will be looking to see if there are any easy ways to reduce
hyperreal web traffic. 

I am exploring many options at this point for more bandwidth
off-Organic.  Bandwidth can be made available in many forms - if we
can find an off-site mail relay willing to forward mailing list mail
for us, for example, or someone willing to mirror Hyperreal web
content. 

        Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  www.apache.org  hyperreal.com  http://www.organic.com/JOBS


Re: list delays

Posted by Brian Behlendorf <br...@organic.com>.
On Thu, 12 Jun 1997, Marc Slemko wrote:
> On Thu, 12 Jun 1997, Brian Behlendorf wrote:
> 
> > Let's get the mirror stuff up asap.  As of this morning Apache traffic
> > was over half the total HTTP traffic from hyperreal.
> 
> And how much was downloads from /dist vs. other stuff?  If most is from
> dist, then just a CGI to redirect downloads should help.  If not, then
> something more may be necessary.  I don't like the multiple A record
> thing.  Perhaps a frontdoor script that redirects to mirrors?

The vast majority was from /dist.  From 11am (around the time the
front page was changed) to now:

14811   163724232       www.apache.org
809     76209307        www.apache.org/dist
4417    47138083        www.apache.org/docs
126     34414041        www.apache.org/dist/apache_1.2.0.tar.gz
5232    26932884        www.apache.org/images
211     20923800        www.apache.org/dist/binaries
1576    20683054        www.apache.org/images/apache_logo.gif
662     19284684        www.apache.org/docs/misc
45      17991146        www.apache.org/dist/apache_1.2.0.tar.Z
882     16236729        www.apache.org/docs/mod

Meaning now we're running about 50% /dist, 30% /docs.  Last night it
was at around 80% /dist, so this is a great improvement.  I'm looking
at the raw bandwidth charts now, and taz.apache.org's bandwidth share
is now smaller than it was; I anticipate that improving more over
time, too. The problem is demand is so elastic... hmm, right *now* FTP
traffic is very high, and I see it may be because I shifted "Old" to
"old", since most of the FTP users right now are mirrors. 

Anyways, I'll keep watching this until Monday, when I leave for south
africa for a week for a conference.  I'll followup with offers for
help privately.  Thanks, everyone.

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  www.apache.org  hyperreal.com  http://www.organic.com/JOBS


Re: list delays

Posted by Marc Slemko <ma...@worldgate.com>.
On Thu, 12 Jun 1997, Brian Behlendorf wrote:

> Let's get the mirror stuff up asap.  As of this morning Apache traffic
> was over half the total HTTP traffic from hyperreal.

And how much was downloads from /dist vs. other stuff?  If most is from
dist, then just a CGI to redirect downloads should help.  If not, then
something more may be necessary.  I don't like the multiple A record
thing.  Perhaps a frontdoor script that redirects to mirrors?

> I am exploring many options at this point for more bandwidth
> off-Organic.  Bandwidth can be made available in many forms - if we
> can find an off-site mail relay willing to forward mailing list mail
> for us, for example, or someone willing to mirror Hyperreal web
> content. 

We could handle relaying for Apache lists here (scanner.worldgate.com; 
good bandwidth, reasonable machine...), and perhaps some others too
depending on volume...  mail me privately if you are interested.