This may get somewhat off topic ...
On Fri, Jul 21, 2000 at 11:15:15AM -0400, Michael T. Babcock wrote:
> The move to lower bandwidth consumption of websites in general has picked up
> speed as well. Many many sites and organisations are taking a stand to
> reduce bandwidth use of websites and the Internet in general.
I would call that rumours.
Alone switching to XML which is coming more and more will probably
put the overhead of markup code compared to visible content far beyond
the current ratio. Thats for the size of the documents.
And I really cant see any site that has reduced the amount of images
on their pages ... more to the opposite, navigation is done in zillions
of small images compared to one with imagemap, each are gets own nifty
images and so on ...
> Bandwidth consumption on the Internet is important enough that most routers
> and software routers (including Linux) now include options to make use of
> RED (random early detection) in their queuing systems to drop IP packets and
> cause TCP streams to slow down and not fill their pipes. Major routers are
> clogging and locking up at major websites.
If you have a line that can't handle the load, get a bigger/additional one.
I have no sympathy for so called ISPs that that try to stay in business
with dumping prices which they implement by either using some $1500 Linux
routers that can't cope with the load instead of buying some real
(and expensive) routers from companies who's names we all know, or
they have those routers but they can't/are unwilling to pay a line that
could handle the bandwidth needed.
> This is a real issue. If you
> think opening a few dozen connections to a major ISP who has to handle
> thousands is not going to make a difference, think again.
I probably understand you wrong on this.
But one always have a critical point, where adding one more piece
to it makes the system collapse. And there is always a solution
to manage this.
I have a checkpassword perl script on our POP Server. Ran smoothly
for about 2 years and then - without any notice - we'd reached the
critical point and the load on the POP Server jumped from one day to
the other from an average of 1.5 to 2 during prime time hours to about
10-15 and sometimes more.
I had a look at it for 3 oder 4 days, did some analysis and then, I sat down
and reimplemented the checkpassword program in C.
Guess what? 5 minutes after I had exchanged the perl code with the C
binary the load was down to 0.3 to 0.7.
> Mind you, I think a simple solution includes adding an option to drop
> incoming connections (on tcpserver) from IPs that already have connections
> open.
This is probably to simple.
Why should I drop maybe 50 connections from one host if I have no others?
And who says that those 50 connections are redundant and result from
always the same mail send 50 times to 50 different users on my host?
We have 40.000-60,000 tcpserver connects a day on each of our
mailservers (which are in the range of 300.68-MHz 686-class, 128 MB RAM).
No problem at all, I'd say they could handle more than double the
connections.
Maybe this is the reason I don't care about those limits.
And at the end one general note about qmails delivery strategy.
If you put aside the bandwidth overhead qmail has and the CPU/memory
overhead sendmail has in sorting a 150,000 user mailing list with
all the race conditions involved I can think of, there are some memory
frazzles from math lessons that showed that it's the fastest for
all "customers" if everyone is treated the same in one queue and
no multi-jobs (i.e. on person stands there trying to get 10 jobs
for others persons done, too) allowed. And that exactly is the behaviour
qmail sticks to. Always stand at the current end of the queue with
every single message (and qmail-smtpd enforces this by not allowing
more than one "MAIL FROM" per session).
\Maex
--
SpaceNet GmbH | http://www.Space.Net/ | Stress is when you wake
Research & Development | mailto:[EMAIL PROTECTED] | up screaming and you
Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0 | realize you haven't
D-80807 Muenchen | Fax: +49 (89) 32356-299 | fallen asleep yet.
