httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: apache performance note (fwd)
Date Sat, 13 Sep 1997 07:07:36 GMT


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

> 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?

Yeah sure it will do this (yup Marc many routers do this, Ciscos do as
well for example)... but the point is that it will err on the side of
caution and refuse access in this case, and will probably allow it after a
reload. 

As far as end-to-end latency goes ... even folks who get their
connectivity via satellite could easily have their reverse DNS served by a
more well connected server.  scott.aq has well connected forward DNS for
example ...

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

Did you mean to cc the original submitter? 

Dean

> -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