Re: ideas

On Sun, Jun 11, 2000, Henrik Nordstrom wrote:
> Regarding the SMP question..
>
> Do you remember the discussion we had earlier about breaking Squid up in
> various separate components/processes:
>
> * Connection manager(s)
> * Store index manager
> * Disk I/O threads/daemons
> * DNS cache manager
> * System monitoring/control manager
> * What else there is to separate from the rest..
>
> That design plays quite well with SMP configurations. Normally there
> will be one connection manager/CPU, one store index manager, one DNS
> cache manager and probably at least one disk I/O thread/daemon per
> spindle.
>
> For asymetric multi processing you would probably use one connection
> manager / CPU, more than one index manager, and some kind of close
> peering between the index managers.
>
>
> To dig a bit deeper in the design I intended:
>
> a) All connections, both client connections and outgoing connections to
> other servers are managed withing the connection manager. If a request
> is received by a connection manager, then it is this connection manager
> who contacts the next hop in the request forwarding chain.
> b) Data received from the origin servers are mirrored to the storage
> where applicable. There are also some other types of feedback going from
> the connection managers to the store index manager like "make sure this
> object is no longer cached", or "this object is still up to date".

Hmm. How would the feedback and 'mirroring' occur? I thought about your
proposal and I decided to extend it a little to my proposal since all
the flexibility is there without having to hack in weird methods of
communiation between the connection manager and the storage manager.

> c) The store/index manager provides two interfaces:
> i1) Hints in the form of a cache digest or something similar, quickly
> telling for sure that an object is NOT in the cache. This is to provide
> a very fast path for most cache misses.
> i2) A request interface where the connection manager(s) request a
> stored object. Used when (i1) indicates that the object might be in the
> cache.

Right.

> d) The connection managers should be self supporting. If any of the
> other components have failed then bypass that component.
> e) The system monitoring/control manager only monitors the other
> components and makes sure everything is up and running. It is also
> responsible to bring down all components in a controlled manner when
> asked to.

Ok. You're talking about seperate processes here, right? I'm talking
about having it all as one process with a single comm/callback thread
per CPU. I guess if designed right the modules could support either
IPC or callback notification depending upon your orientation, but
my motivation for keeping it all in one process as much as possible
stems from my desire to have this compile relatively cleanly under
DOS at some stage.

> As I said earlier a design like this requires that the request
> forwarding is rewritten to be centered around a request or request
> forwarding and NOT a StoreEntry. Store entries will only exist in the
> store index manager and/or disk I/O.

Yup. I totally agree here.

> Connection sharing will probably only be possible within a connection
> manager, and there might be a little higher latency on cache hits, but
> that is fairly small price to pay for the added scalability and
> realibility gained from having a design like this.

Connection 'sharing' ? DO you mean server to multiple client connections
simultaneously? Hmm. I didn't want to support that. I wanted there to be
persistent connections but server->multiclient IMHO should be handled
by the storage manager. A client-speaking clientlet and server-speaking
servlet should only have two ends - the request end and the socket end.
The storage manager should handle multiple clients and multiple srvers
(revalidation). That said, something like request pipelining could be
a fun thing, where a clientlet can support multiple servlet connections
but only lets one transfer data at a time..

Adrian

-- 
Adrian Chadd			Build a man a fire, and he's warm for the
<adrian@creative.net.au>	rest of the evening. Set a man on fire and
				he's warm for the rest of his life.