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 19:47:07 GMT
	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
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).

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

-Philip

	---------- Forwarded message ----------
	Date: Thu, 4 Sep 1997 12:20:36 -0700 (PDT)
	From: Dean Ritchie <ritchie@wsu.edu>
	To: dgaudet@apache.org
	Subject: apache performance note

	Performance issue on Apache:

	In monitoring our web-server response times, we discovered that there were some requests
that mysteriously required a very long time to fill (something like 75 seconds, in many cases).
 Further investigation led us to the discovery that the bulk of this time is consumed in nameserver
resolution, primarily for the operation of translating the IP address to a symbolic name sequence.
 The long delay consistently occurred when the nameserver was unable to resolve the IP number
into a name.

	When we consulted the newsgroup on the issue, the advice we got was to reconfigure Apache
to not do the name lookup.  This advice is probably wise, but we had gone down the road some
distance, and our webmaster was relying on the lookup to restrict access to some of our local
pages to local workstations.

	The answer we found comes from the O'Reilly book "DNS and BIND" by Paul Albitz and Cricket
Liu.  The segment on Undocumented Library Routines, beginning on p. 296 in my copy, describes
the _res structure and the res_init function.  We modified http_main.c to include resolv.h,
and then added a call to res_init to the main( . . .) function, followed by setting _res.retry
and _res.retrans to 1.

	The result of this change is that Apache only tries one time to look up a name, and only
waits one second for that lookup to complete.  This appears to be completely adequate for
resolving local addresses, as well as any addresses that happen to be cached in the local
nameserver.  In case the nameserver can't resolve the address, the IP address is passsed along
to the webmaster routines, and in our case, the special requests would be denied.  As far
as we can tell, these requests would be denied even if the name lookup were successful, so
this modification has no negative effects.

	What we understand about the nameserver operation implies that the nameserver continues to
look for the requested address, so that a later request will find the actual name in the nameserver
cache, so that subsequent requests from the same address would have their name resolved for
the apache logs.

	We suggest that this or a similar change be considered for subsequent versions of Apache.
 Since the software comes out with the name-lookup on by default, it's a good bet that there
are many webservers on the network which do the name lookup.  The effect of this is that workstations
from very distant parts of the network must wait an additional several seconds for the  name
to be looked up across the network before the requested data begins to be sent.  In addition,
there are some nameservers in the network that don't include the name lookup information,
so that these reverse lookups always time out for workstations from those segments.  This
resulted, in our case, in a local ISP's customers waiting 75 seconds for each of the web pages
we offer for the public.  After we discovered the problem, we contacted the provider and they
have corrected their problem.  However, we also noticed out-of-town addresses that timed out
for the full 75 seconds, indicating that there are netwo!
rk segments out there with the same problem.



Mime
View raw message