- From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
- Date: Fri, 28 Jul 95 23:45:10 CDT
- To: connolly@beach.w3.org, mshapiro@ncsa.uiuc.edu
- Cc: uri@bunyip.com
> From: "Daniel W. Connolly" <connolly@beach.w3.org> > But... it seems that resolution of path URNs would involve failed > DNS lookups, which take a long time, no? Thanks for your interest. Michael Shapiro can give a better answer regarding performance since he did a variety of tests. Generally, it is fast (less than a second with a good local resolver) and I can say why the problem you are concerned about does not occur when you think it might. > Under "Resolving the URL-sets into the Resource" it says "After > constructin a list of URL-sets, ..." This is partly an abstract description, so one does not actually need to construct all the URL-sets before starting to resolve the most specific ones. However,... > So I get the impression that the, > for example, http transactions don't start until after the DNS > transactions are done. That is true. Or at least, the URL resolution doesn't start until the most specific resolver is found, but one could start somewhere in the middle of the path, look for more specific resolvers, and if they fail, only then look for higher level backup resolvers. But the thing you are concerned about is ... > And failed DNS lookups, in my experience, take 15 to 120 minutes. Not in this case. The long failures (I've never waited *that* long) are due to not getting an authoritative answer (or maybe no answer at all) so the resolvers keep looking around or trying to get through to a server that is down. The failure at the bottom of the DNS part of path resolution is just as fast as a successful resolution when the authoritative answer is known. I was concerned previously about even that one failure hit on the remote server, since it must always occur for every path resolution, unless the local caches remember the negative hit from previous attempts for a similar path. We had a workaround (described in the previous version of the draft) to avoid that one negative hit, but it now seems not worth the complexity, since it requires effectively caching that same negative info in TXT form. Also, we expect that most path name resolution would happen in the same neighborhood as the URL resolution to get the resource itself, so one extra UDP request is not that much of a burden. > Are path: implementations expected to exploit parallelism, or is > there some technique for avoiding failed DNS lookups? Implementations are expected to make use of local caches via DNS at least. DNS resolution can exploit some parallelism and so path resolution can use that too. If path's turn out to be used alot, then resolvers and DNS itself might be changed in various ways to facilitate even faster path resolution. > In general, do you have any performance data? Estimates? Good question. We also wanted to announce availability of our mod of the CERN proxy server to do path resolution, so people could try it out and not just believe our data. RSN. dan
Received on Saturday, 29 July 1995 00:45:33 UTC