On 10 Aug 96 at 12:10, squid-users@nlanr.net wrote:
> Um. I guess that I was a bit violent in my statement about "ripping
> out" the ipcache system. I was a bit frustrated with what I perceive
> as unnecessary complexity in the address resolution mechanism. I
> can see some advantage to the method by which squid manages resolver
> queries through the external servers. The first resolver query
> may indeed take several seconds to respond.
... and meanwhile block all other activity in the proxy !
> So perhaps some startup performance is gained through this mechanism.
> I do not see any advantage to the current implementation of the ipcache.
Non blocking name<->IP resolution : a DNS request may take several seconds ...
and squid _MUST_ continue serving other clients during this time ...
> My primary argument is with the internal data-structure maintained
> by routines in ipcache.c. Based only on behavioral testing, including
> packet traces I assert that squid only makes use of the first ip
> address returned from dnsserver. Further, squid refreshes the
> cache infrequently. If squid stays up for a long period of time
> the ipcache becomes stale.
You've got some options in the config file to tune this behaviour (for
instance positive_dns_ttl, which change the expiration TTL for a DNS
entry in ipcache)
> I suggest that a better approach would be to make use of the
> dnsservers for every name query. Thus taking advantage of the
> cache maintained by named. I believe that it would be impossible
> for squid to do a better job of caching IP addresses than BIND
> already does.
You are right on this point ! ;-)
> It is unfortunate that the standard resolver api does not support
> an asynchronous interface. So a pair of routines that interface
> with the dnsservers and the select loop might be the best approach.
Yes, that's exactly what dnsserver does ... but the way asynchronous
DNS requests are made in SQUID is a little bit complicated ! ^_.
Pierre-Yves
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pierre-Yves KEREMBELLEC Phone # +33 1 46 12 67 50
Solutions Vocales Fax # +33 1 46 12 67 00
40, rue Gabriel Crie E-mail pyk@sv.vtcom.fr
92245 Malakoff Cedex, France WEBMaster / FTPMaster
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2i
mQCNAzDQewgAAAEEAKoYh1EHqDjL+ZiZ5ObcQgHQcPE1w7ZN6jUvZ09+Jcp4TKCQ
okisJq8Ojmafc5my20WsyHlP2znopn/WLaq9LA4RKQqpWt35zLOfipl4hA8BOM9n
VS5EzgLkK2lkV5wG2tlBbKa3Ofk2uyyw8mWPS2L+8Dh0H+Tfovq3GB6d5ar5AAUR
tClQaWVycmUtWXZlcyBLZXJlbWJlbGxlYyA8cHlrQHN2LnZ0Y29tLmZyPokAlQMF
EDDzsdr6txgeneWq+QEBCucD+wQEcDpOaMkkdv30MfPrBmFuhZLnjokMrYq6QBYw
biIZTXsj3ckuBC5IFn3HbUX9UccXnCBo5JQYU0pslPy3X2jNpAaZiJeCOYecp1+x
BIQfAQkTdVNGQfaUVxuT/SEseyynZJwjrleI5cpOJVCO4il92i9V5Pb289meHByJ
UW1k
=3Nc1
-----END PGP PUBLIC KEY BLOCK-----
Received on Mon Aug 12 1996 - 01:20:14 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:32:47 MST