Date: Tue, 8 Jun 93 16:37:52 -0400
From: "Chris Weider" <clw@merit.edu>
Message-Id: <9306082037.AA05546@merit.edu>
To: e-krol@uiuc.edu, weibel@oclc.org
Subject: Re: scalability of table lookup
Ed:
This is why the URL is cached with the URN.... You only have to do an
expensive lookup when your old, fast pointer is incorrect. There's no way
to tell without solid data, but I would expect a given pointer to be good for
a month at least. So if you have a one second wait for your favorite resources
once a month and speedy access all the rest of the time, people can live `
with that... they already do for other types of net operations.
Once the URL has been cached you're home free. And if you can't stand even that,
I suppose its possible to build servers that update their caches whenever they have spare cycles.
Chris
In addition, this need to resolve is likely to be spread across a large number
of connections... if it takes 2 seconds to grab a new URL and cache it, then
there's a 2 second window where everyone who's using *this particular resource*
has to wait. Then it's good for a month again, and someone who tries to access
this 5 seconds later sees no wait at all.
Chris
> From uri-request@mocha.bunyip.com Tue Jun 8 15:08:57 1993
> Received: from mocha.bunyip.com by merit.edu (5.65/1123-1.0)
> > id AA29025; Tue, 8 Jun 93 15:08:48 -0400
> Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b)
> id AA01025 on Tue, 8 Jun 93 14:07:50 -0400
> Received: from ux1.cso.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
> id AA01021 (mail destined for /usr/lib/sendmail -odq -oi -furi-request uri-out) on Tue, 8 Jun 93 14:07:45 -0400
> Received: from [128.174.33.173] (maced.cso.uiuc.edu) by ux1.cso.uiuc.edu with SMTP id AA23132
> (5.67a8/IDA-1.5 for <uri@bunyip.com>); Tue, 8 Jun 1993 13:06:44 -0500
> Date: Tue, 8 Jun 1993 13:06:44 -0500
> Message-Id: <199306081806.AA23132@ux1.cso.uiuc.edu>
> X-Sender: krol@ux1.cso.uiuc.edu
> Mime-Version: 1.0
> Content-Type: text/plain
> To: weibel@oclc.org (Stu Weibel)
> From: e-krol@uiuc.edu (Ed Krol)
> Subject: Re: scalability of table lookup
> Cc: uri@bunyip.com
> Status: R
> Stu writes:
> > Is the point of UR*s to provide instantaneous access to all
> > resources under all conceivable circumstances, or is it to provide a
> > reliable way to identify and retrieve a resource across time in a
> > changing environment (both are of obvious value)?
> >
> > I take it Ed's concern that (.5 sec x2) may be too slow is based on
> > the requirements of Mosaic and similar systems that will try and
> > service immediate demands for linked objects distributed across the
> > net?
> I guess I just look at the numbers of servers who might use this
> facility and think it is not possible to build a centralized one
> fast enough to do the job. I know this is only a guess but if we assume
> that someone uses this service to move to another gopher menu every
> 10 seconds (every gopher server in the world handles .1 transaction/second)
> then the URN resolution traffic without optimization would be around 55/sec.
> If we assume the magic 8%/month growth on the Internet that means that just
> gophers under those constraints would tax a 200 t/s server in a bit over 2
> years.
> Now consider that .1 is a paltry peek transaction rate for most gophers
> (That is about what the average weekly transaction rate at the uiuc gopher
> is) and that it is only one service of then net. If you add the web and
> ftp and whomever else decides to use the service I think we can easily hit
> 200 t/s the day we turn it on.