Re: ideas

Adrian Chadd wrote:

> * if separate processes are used for each CPU for SMP performance, how
> do you handle multiple clients across separate processes talking to
> the storage manager which then talks to one (or two depending if
> the object needs revalidation) servers ?

I simply don't do it.

The network I/O processes handles all the request forwarding, and
mirrors retrieved data to the storage as it is retrieved. It is also the
network I/O processes who contact the next hop for revalidation and then
feeds back the result to the store.

To avoid the odd situations discussed before about clients with varying
speed or the main client aborting, live object connection reuse is
limited to inside a single network I/O manager. Request arriving at
other network I/O managers before the object has been fully retrieved
won't see the object and process it as a cache miss. If this is seen as
a problem, then we have the option to look into file descriptor passing
or cross-network-I/O-manager connections to hand the client connection
over to the correct network I/O manager, but I seriously doubt this will
ever get done given the rather small benefit it provides.

The network and store will only be loosely coupled. All storing and
updates of objects is in the network I/O managers point of view
asynchronous.

Details on how to most efficiently handle cache hits remains to be
defined. Yes, there will be a somewhat higher latency for hits than
today, but I don't think it will be that much higher. I estimate it will
mostly be noticed for ICP in sibling relations (there is a possible fast
path for ICP in parent relations)

> * If you have separate processes for different IO types (say you have a http
> module, a realmedia module, an FTP module..) how do you efficiently stream
> between them?

I had not planned to, but yes the framework might be extended to support
FTP and/or streaming proxying, however each such proxy process will be
self contained with both client and server handlers. The HTTP proxy will
have server handlers for retrieving all the common URL types much like
todays Squid but without any built in storage.

> I still like the idea of a monolithic process for various reasons, but
> I can be swayed with pseudo-code. I will attempt to throw together
> some pseudo-code describing my idea tomorrow. Henrik and anyone else,
> please do the same. I think this will help us all in sorting out a final
> design that we can start coding on.

The request forwarding is mostly a monolithic process, except that there
might be more than one such process. The main coding difference from
today is that the object store is separated from the networking, and
that the request forwarding is centered around request forwarding, and
not a StoreEntry.

/Henrik
Received on Mon Jun 12 2000 - 18:56:25 MDT