Re: Direct mapped like caching

Andres Kroonmaa wrote:
>
> On 6 Nov 2000, at 15:14, Alex Rousskov <rousskov@measurement-factory.com> wrote:
>
> > In other words, do we really want to see Squid as a huge
> > collection of super-compatible-and-inter-exchangeable modules? If yes,
> > a *lot* of performance-unrelated work will need to be done first (and
> > supporting a very diverse collection of approaches will most likely
> > hurt performance at least a bit). If no, then compatibility and
> > similar arbitrary choices will need to be made to select a small
> > subset of the "best" modules.
>
> I think we should try to determine, what needs to be supported,
> review the list of approaches, find equal in features, and decide
> if we need to support old style. I think it may occur that we can
> implement old style ontop of new style, if only needed.
> Still, we are very fast approaching point where squid is not fast
> enough to handle loads and disk sizes required. I'd rather focus
> on performance and efficiency rather than internal compatibility.
> We can draw a line between <3.0 and >=3.0, and drop stuff that is
> slowing down further improvements.

I also come down firmly on the side of dropping that which is no longer
effective, in favor of allowing development to go more quickly on the
things we do need.

I think it's what Henrik and Adrian have been envisioning, in fact, even
if it hasn't been summed up in so many words. Squid does need to
continue becoming more modularized so that experiments like the ReiserFS
thing can happen for every aspect of Squid, not just the storeio
interface. But, just like with the storeio thing, all of the old ways
(the old async and ufs) methods had to be brought into line with the new
modular design. That was labor that we may not want to reproduce for
each aspect of Squid, if there is a better general purpose design that
can be put in it's place. What I mean by that, is that if there is some
way to create a general purpose storage manager (to replace the
swap.state) within a modular framework, and I believe there definitely
is, then why not drop swap.state entirely and don't try to bring it into
the new modular storage manager code at all? (Of course...there should
also be a modular way to leave out the generic storage manager as well,
if some storeio module coder thinks they know a better way to do it, or
if the goal of the module is different--such as memory savings over
performance.)

I think that maybe we should cut some old ties when 3.0 goes into
development. Obviously some things need to stick around, such as UFS
for those who are using Squid on non-dedicated systems and want the
flexibility of using a standard partition. But it can be updated to use
the new storage manager along with the rest. I also tend to think there
should be a concerted effort to unify platform versions as much as is
reasonable to maxmimize code re-use and minimize developer effort. We
now have an awful lot of configuration options at compile time. I'm not
sure I'm convinced that all of those should remain, particularly if a
new design requires that significant amounts of code must be rewritten
to bring it along with us.

My .02

BTW-I've posted tarballs at my website of the reiser_raw/butterfly
squid, if folks want to take a look. I've also written to the
SourceForge site folks to open up the CVS there, so that it will be
available via anonymous CVS. But I think merging it into the
squid.sourceforge.net cvs will come soon as well. (The website is here:
http://www.swelltech.com/pengies/joe/squidng.html )
                                  --
                     Joe Cooper <joe@swelltech.com>
                 Affordable Web Caching Proxy Appliances
                        http://www.swelltech.com
Received on Tue Nov 07 2000 - 01:01:55 MST