httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@worldgate.com>
Subject Re: 30 second response time from apache and zeus servers (fwd)
Date Mon, 10 Mar 1997 06:57:04 GMT
The latest BIND does do negative caching:

  NCACHE (origin: USC/ISI)
	  enables negative caching. We cache only authoritative NXDOMAIN or
  authoritative NOERROR with zero RR count. Non-authoritative NXDOMAIN answers
  now contain NS records in the authority section. Non-authoritative NOERROR
  responses have no authority or additional records to differentiate them from
  referrals. They are cached for NTTL secs (currently 10 minutes) and are timed
  out when the ttl expires.
	  you probably want this, it is on by default.

Shorter ttl than average, but it really has to be that way.  The
archaic 4.9.3-P1 on taz almost certainly doesn't have negative
caching.

It should not take 30 seconds to respond to an unresolved hostname.
In some cases where the server is not answering, yes, but in this
case the server currently responds with a nxdomain right away so there
should be no delay unless something is broken somewhere.

It takes a lot more effort than most people think to implement
an internal resolver with cache (Netscape sure can't do it right...)
and it makes sense to use named.  In any case, any sort of caching,
including both in memory document and hostname caching, isn't pretty
in Apache right now because you need some sort of IPC to share
between processes.  Tell him that this has nothing to do with Apache
as a server but simply has to do with the decision of the admin of
that particular website to punish those who can't setup proper
reverse DNS entries.  <g>  Oh yea, and tell him it is lame to use
HTML in mail for no reason.

I think Roxen has a seperate process that handles DNS lookups.

On Sun, 9 Mar 1997, Brian Behlendorf wrote:

> 
> Nice.  So, should I turn off reverse DNS, recommend to him that he
> properly configure reverse DNS, somehow tune my named to cache failures
> (how?) or what?  Kinda cool that he has to pick something relatively puny
> to critique.  :)
> 
> 	Brian
> 
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> brian@hyperreal.com     http://www.apache.org     http://www.organic.com/jobs
> 
> ---------- Forwarded message ----------
> Date: Sun, 09 Mar 1997 22:06:10 -0800
> From: Steve Kirsch <stk@infoseek.com>
> To: brian@apache.org, damian@zeus.co.uk
> Cc: cjl@infoseek.com, wchang@infoseek.com, jackiew@infoseek.com,
>     adf@infoseek.com, cshih@infoseek.com
> Subject: 30 second response time from apache and zeus servers
> 
> I wanted to alert you guys that both the www.apache.org and
> www.zeus.co.uk
> 
> have 30 second response times when I tried access from my home machine
> (which
> 
> uses a dynamically assigned IP address).
> 
> 
> Apparently, I suspect you are trying to do a reverse name lookup on
> every
> 
> HTTP request, and are not responding to the request until you have a
> response from
> 
> your DNS. And if the response is unknown, you are continuing to look up
> the same
> 
> address each time, rather than cache it as being unknown.
> 
> 
> As a result, people like me accessing from home get abysmal response time
> from your
> 
> servers. As the log below shows, the TCP packets are getting through just
> fine, but
> 
> there is a 30 second lag time until the server sends a response.
> 
> 
> So I do find it quite ironic that the supposedly "fastest" servers on the
> planet,
> 
> are, in certain cases like mine (which are not all that unique), the
> slowest servers
> 
> on the planet.  
> 
> 
> Reverse name lookup is more effectively done by a log analysis tool, than
> on-the-fly.
> 
> 
> It's possible that there are other causes, so I welcome your response.
> 
> 
> Here's the snoop trace for apache. The one for zeus is similar:
> 
> 
> <bigger>snoop -x48,100 -tr -d le0 between 198.5.208.92 taz.apache.org
> 
> Using device /dev/le (promiscuous mode)
> 
>   0.00000 198.5.208.92 -> taz.apache.org TCP D=80 S=1128 Syn Seq=3405100
> Len=0 W
> 
> in=8192
> 
>  
> 
>            0: 2000 8aed 0000 0204 05b4 0261               ..........a
> 
>  
> 
>   0.00597 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Syn Ack=3405101
> Seq=103
> 
> 1158339 Len=0 Win=8576
> 
>  
> 
>            0: 2180 153f 0000 0204 0218 1818              !..?........
> 
>  
> 
>   0.15405 198.5.208.92 -> taz.apache.org TCP D=80 S=1128    
> Ack=1031158340 Seq=
> 
> 3405101 Len=0 Win=8576
> 
>  
> 
>            0: 2180 2960 0000 3f88 6f50 1022              !.)`..?.oP."
> 
>  
> 
>   0.15723 198.5.208.92 -> taz.apache.org TCP D=80 S=1128    
> Ack=1031158340 Seq=
> 
> 3405101 Len=0 Win=32768
> 
>  
> 
>            0: 8000 cadf 0000 3f88 6f50 1022              ......?.oP."
> 
>  
> 
>   0.30480 198.5.208.92 -> taz.apache.org TCP D=80 S=1128    
> Ack=1031158340 Seq=
> 
> 3405101 Len=468 Win=32768
> 
>  
> 
>            0: 8000 9dd0 0000 4745 5420 2f64 6f63 732f    ......GET
> /docs/
> 
>           16: 6d6f 642f 6d6f 645f 6173 6973 2e68 746d   
> mod/mod_asis.htm
> 
>           32: 6c20 4854 5450 2f31 2e30 0d0a 4163 6365    l
> HTTP/1.0..Acce
> 
>           48: 7074 3a20 696d 6167 652f 6769 662c 2069    pt: image/gif,
> i
> 
>           64: 6d61 6765 2f78 2d78 6269 746d 6170 2c20    
> mage/x-xbitmap,
> 
>           80: 696d 6167 652f 6a70 6567 2c20 696d 6167    image/jpeg,
> imag
> 
>           96: 652f 706a                                  e/pj
> 
>  
> 
>   0.34918 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80     Ack=3405569
> Seq=103
> 
> 1158340 Len=0 Win=8576
> 
>  
> 
>            0: 2180 278c 0000 0000 0000 0000              !.'.........
> 
>  
> 
>  27.62119 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80     Ack=3405569
> Seq=103
> 
> 1158340 Len=512 Win=8576
> 
>  
> 
>            0: 2180 0770 0000 4854 5450 2f31 2e31 2032    !..p..HTTP/1.1
> 2
> 
>           16: 3030 204f 4b0d 0a44 6174 653a 2053 756e    00 OK..Date:
> Sun
> 
>           32: 2c20 3039 204d 6172 2031 3939 3720 3138    , 09 Mar 1997
> 18
> 
>           48: 3a30 353a 3330 2047 4d54 0d0a 5365 7276    :05:30
> GMT..Serv
> 
>           64: 6572 3a20 4170 6163 6865 2f31 2e32 6238    er:
> Apache/1.2b8
> 
>           80: 2d64 6576 0d0a 436f 6e74 656e 742d 5479   
> -dev..Content-Ty
> 
>           96: 7065 3a20                                  pe:
> 
>  
> 
>  27.62389 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80     Ack=3405569
> Seq=103
> 
> 1158852 Len=512 Win=8576
> 
>  
> 
>            0: 2180 1a02 0000 6520 7072 6f63 6573 7365    !.....e
> processe
> 
>           16: 6420 6279 0a74 6869 7320 6d6f 6475 6c65    d by.this
> module
> 
>           32: 2e0a 3c21 2d2d 2570 6c61 696e 7465 7874   
> ..<<!--%plaintext
> 
>           48: 2026 6c74 3b3f 494e 4445 5820 7b5c 7474     &lt;?INDEX
> {\tt
> 
>           64: 2068 7474 7064 2f73 656e 642d 6173 2d69    
> httpd/send-as-i
> 
>           80: 737d 206d 696d 6520 7479 7065 2667 743b    s} mime
> type&gt;
> 
>           96: 202d 2d3e                                   -->
> 
>  
> 
>  28.10669 198.5.208.92 -> taz.apache.org TCP D=80 S=1128    
> Ack=1031159364 Seq=
> 
> 3405569 Len=0 Win=32768
> 
>  
> 
>            0: 8000 c50b 0000 43e5 7c50 1022              ......C.|P."
> 
>  
> 
>  28.11847 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80     Ack=3405569
> Seq=103
> 
> 1159364 Len=512 Win=8576
> 
>  
> 
>            0: 2180 65cb 0000 7470 642f 7365 6e64 2d61   
> !.e...tpd/send-a
> 
>           16: 732d 6973 2061 7369 733c 2f63 6f64 653e    s-is
> asis<</code>
> 
>           32: 3c2f 626c 6f63 6b71 756f 7465 3e0a 7468   
> <</blockquote>.th
> 
>           48: 6973 2064 6566 696e 6573 2074 6865 203c    is defines the
> <<
> 
>           64: 636f 6465 3e2e 6173 6973 3c2f 636f 6465   
> code>.asis<</code
> 
>           80: 3e20 6669 6c65 2065 7874 656e 7369 6f6e    > file
> extension
> 
>           96: 2061 7320                                   as
> 
>  
> 
>  28.12133 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80     Ack=3405569
> Seq=103
> 
> 1159876 Len=512 Win=8576
> 
>  
> 
>            0: 2180 86e5 0000 2061 7265 2073 656e 7420    !..... are 
> sent
> 
>           16: 3c65 6d3e 6173 2069 733c 2f65 6d3e 2073    <<em>as is<</em>
> s
> 
>           32: 6f20 6173 2074 6f0a 7465 6c6c 2074 6865    o as to.tell
> the
> 
>           48: 2063 6c69 656e 7420 7468 6174 2061 2066     client that a
> f
> 
>           64: 696c 6520 6861 7320 7265 6469 7265 6374    ile has
> redirect
> 
>           80: 6564 2e0a 3c62 6c6f 636b 7175 6f74 653e   
> ed..<<blockquote>
> 
>           96: 3c63 6f64                                  <<cod
> 
>  
> 
>  28.12392 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Fin Ack=3405569
> Seq=103
> 
> 1160388 Len=412 Win=8576
> 
>  
> 
>            0: 2180 1489 0000 4f44 5926 6774 3b20 3c62    !.....ODY&gt;
> <<b
> 
>           16: 723e 0a26 6c74 3b2f 4854 4d4c 2667 743b   
> r>.&lt;/HTML&gt;
> 
>           32: 0a3c 2f63 6f64 653e 3c2f 626c 6f63 6b71   
> .<</code><</blockq
> 
>           48: 756f 7465 3e0a 4e6f 7465 733a 2074 6865    uote>.Notes:
> the
> 
>           64: 2073 6572 7665 7220 616c 7761 7973 2061     server always
> a
> 
>           80: 6464 7320 6120 4461 7465 3a20 616e 6420    dds a Date: 
> and
> 
>           96: 5365 7276                                  Serv
> 
>  
> 
>  28.49997 198.5.208.92 -> taz.apache.org TCP D=80 S=1128    
> Ack=1031160388 Seq=
> 
> 3405569 Len=0 Win=32768
> 
>  
> 
>            0: 8000 c10b 0000 f882 ef50 1080              ........P..
> 
>  
> 
>  28.58074 198.5.208.92 -> taz.apache.org TCP D=80 S=1128    
> Ack=1031160801 Seq=
> 
> 3405569 Len=0 Win=32356
> 
>  
> 
>            0: 7e64 c10a 0000 f882 ef50 1080              ~d......P..
> 
>  
> 
>  28.75340 198.5.208.92 -> taz.apache.org TCP D=80 S=1128 Rst Seq=3405569
> Len=0 W
> 
> in=0
> 
>  
> 
>            0: 0000 3f7b 0000 43fc 4c50 1022              ..?{..CLP."
> 
>  
> 
> </bigger>
> 


Mime
View raw message