httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philip A. Prindeville" <phil...@enteka.com>
Subject Re: apache performance note (fwd)
Date Thu, 04 Sep 1997 21:08:35 GMT
	Date: Thu, 4 Sep 1997 14:04:22 -0600 (MDT)
	From: Marc Slemko <marcs@worldgate.com>
	To: new-httpd@apache.org
	Subject: Re: apache performance note (fwd)

	On Thu, 4 Sep 1997, Philip A. Prindeville wrote:

	> 	Date: Thu, 4 Sep 1997 12:24:26 -0700 (PDT)
	> 	From: Dean Gaudet <dgaudet@arctic.org>
	> 	To: new-httpd@apache.org
	> 	Subject: apache performance note (fwd)
	> 
	> The description below sounds highly suspect.  First, what if
	> some router along the way doesn't have an Ethernet address for
	> the name server in question?  It will drop the packet, waiting
	> for the sender to retransmit (by which time the ARP request

	Erm... not on most boxes.

It happens on 3Com netbuilders, and on most ATM LANs as well:
since the VC has to be opened, all IP traffic will be tossed
until the call completes.  I understand their reasons for doing
this: it simplifies things (since you don't have to flush a
bunch of packets if your call doesn't go through) and it saves
on packet buffering (output controller buffers in ATM switches
are one of the things that things that make switches difficult
and expensive to build).  Indeed, for a long-haul (IXC) switch,
you need enough output port buffering to hold one window's
worth of data *at each hop* to stop a TCP connection from
stalling (and to prevent concurrent flows from negatively
impacting each other).

One of my colleagues from Bellcore, Will Leland and Craig
Partridge did some interesting work on how TCP flows (when
you look at them as groups) tend to be self-similar.  Tony
Bogovic (also from Bellcore) had some interesting data on
TCP performance over ATM, but I don't know if it got published
or not.  That was over two years ago, so it probably has been.

I don't know what kind of boxes you are referring to as "most",
since we probably have had very different experiences.

	> will have been answered).  Problem is, most reasonable TCPs
	> (Solaris 2.3 and later not being in that list) have an initial
	> RTT estimate of 2.0 to 5.0 seconds, so the next packet (if
	> your forwarding nameserver or resolver is using TCP) won't
	> come until after you would have given up...
	> 
	> Why don't you just have a caching local name server?  Most of
	> the data you will need will be in it a good percentage of the
	> time.  I can't remember if the latest versions of BIND handle
	> negative caching correctly, though...  but that shouldn't
	> impact you too much if you aren't looking up a lot of
	> non-existant names in the .edu.au or .ac.kr domain (or some
	> equally far-away place).

	Negative caching is normally done with very short TTLs.

Right.  But it is adequate to protect you from a denial-of-service
attack where someone is hitting your (single-threaded) server
(process) with a bunch of requests all with the same bogus name.
Your server doesn't have to keep waiting while it repeatedly looks
up the same bogus name.  It can flush the request right away, before
the request backlog overflows.

	> Anyway, why can't you do your access controls based on IP
	> address?  Or just require authentication via username/password?

	Regardless, lots of people like IP lookups.

Right.  So they should be prepared to wait however long it takes
to look up the name.  DNS is not a real-time service.  If you
want to bound the service response time, then you should probably
nix name service.  That's all I'm trying to say.

	Note that this long timeout does _NOT_ happen in 95% of the reverse
	lookups without hostnames.  Most of them just fail and go on their way.
	It is only if nameservers are unresponsive (as opposed to not 
	being setup) that the problem happens.

Again, our experiences vary.  In the early 90s I was with France
Telecom and some networks, like Germany's DFN, regularly had 2-3
second delays (it's an X.25 network with a very small window size
and end-to-end acknowledgement).  In France we had trouble too
with setting up the top-level name server at one point, and it
wasn't always highly available...  This was actually more the
fault of Renater, who ran the national backbone, and not the
people at INRIA who ran the .FR nameserver (a very competent
bunch form whom I have a lot of respect).

In Montreal in the 80s CRIM didn't see the writing on the wall
and built a DECnet only network despite the fact that 3 major
consortium members had unofficially petitioned for IP and DECnet.
So, we had to run IP (a datagram service) tunneled over DECnet
(a circuit oriented service).  Again, our RTTs often exceeded
1 second, especially for the first packet in a flow.

(Goodness, I've aired a lot of my former employers' dirty laundry 
in the last few paragraphs... hopefully I won't need any
references any time soon... ;-)

My point in a nutshell is that what you see here in the States
is significantly better than what one sees in a lot of other
countries and you should never forget that worse case can be
pretty friggin' awful in some corners of the world...  I know
some people (Medecins sans frontiers) that use IP over VSAT on
a DS-0 channel to surf the Web for epidemiological data from
Africa.  Do you know what 3 hops over satellite is like?  You
have time not only to make a cup of coffee and drink it, but
also plant and harvest the crop before your page is downloaded.

	Lowering the timeout is a valid thing to do in some situations.  It
	is a valid option, but isn't completely portable.  I use it in my
	under-development log resolver program and it would be reasonable
	to add an option to Apache to let them set it.  The exact numbers
	to set them to are open to dispute.

I can agree with that.  As long as we underscore the "some
situations"...

-Philip

P.S.	Did I mention two sites in Tokyo that are literally
	across the street from each other and exchange their
	email with each other though Hawaii?  ;-)  It's a wild
	(read "sick") world out there...

Mime
View raw message