Re: squid rewrite

From: Andres Kroonmaa <andre@dont-contact.us>
Date: Sun, 8 Jun 1997 20:01:35

> From: Henrik Nordstrom <hno@hem.passagen.se>
> Andres Kroonmaa wrote:
> >
> > As your thoughts are quite similar to those I have thought of for
> > quite some time, I would like you to take a look at these ideas and
> > comment aggressively. As it appeares to be too big to include with a
> > mail, here is a URL: http://cache.online.ee/cache/Devel/design.txt
>
> As I am a bit restrictive on the use of shared memory, I beleive that
> the bulk data transfers should be kept inside the same process as much
> as possible. That is that the same process that fetches a object also
> stores it on disk. (and reverse)
>
> By using the same reasoning, ICP (protocol) and the store manager should
> be glued together. the ICP queries requires ultra-fast lookups to see if
> a object is cached, and ICP is fully dependent on that the store manager
> keeps a consistent picture of the cache. (the other parts can actually
> be made to continue to service even while the store-manager restarts).

    Of course bulk transfers shouldn't be done via IPC. Use of shared
 memory just gives fastest possible way to check for a cache hit/miss.
 Other parts of squid also need access to cache metadata. Of course, ICP
 can be made to include store manager and some special protocol to acquire
 and lock files for reading/writing for local service processes. Service
 processes can call for ICP to check for hit/miss and later when object
 headers are recieved call to allocate file for storage and then write
 directly to that file. I guess, almost anything could be done via pipes
 or sockets, just shared mem gives shortcuts and avoids code overhead.
 Since every message over a socket involves a process switch before the
 other end recieves the message, Processing of message might take longer
 than single timeslice and the process switch rate goes up on busy cache.
 High task switch rate is a bad news...
    I would suggest to take a look at possibilities of shared mem and to
 try to solve problems with them, in a long run this would give lots of
 benefits.
 
 
 Andres Kroonmaa,
 MicroLink Online
 vorguadministraator.
Received on Tue Jul 29 2003 - 13:15:41 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:20 MST