RE: Is there a Squid port for NT going on?

True, and I've done the black box type of thing in the past. As I
replied to another respondent, our defined direction is NT, whether I
agree to it or not (I'm actually a closet Mac freak, but...) This would
be true of many corporations trying to reduce support training costs and
zero in on a single platform (whether it's ready or not).

As I said to James (the other poster), I already use a variety of
freeware or freely available programs to actually get the work done
around here. How many of us have to stick to the vendor's tools? If I
couldn't have perl or tcsh, I'd be in a bad position today. The issue is
the OS it runs on. It costs money to deploy another box to do a
function, and squid is not a light weight product for the most part; if
you have a bunch of users you should have a decent box to house it. Most
of our NT servers fit the bill and for the most part they're idle
beasts. For others, you might have a SS5 or SS10 lying around. I don't.
My discarded boxes are really ancient Macs of dubious reliability,
8088's, 286's and sometimes if I'm lucky a 386 with old pre-ATAPI
bioses. Not exactly squid material. Spending $$$ getting a 386 to be a
squid cache plus keeping it alive is not cost efficient.

So if there were a NT version, I'd use it today, as would many others.
I'm also likely to be seeded with BeOS/Intel soon (my name is on the
list :-), and that's an excellent multi-threaded OS. BeOS also could
probably run squid natively on it's posix side, but for best effect, it
would be good to have a multi-threaded version. If the port could cope
with a OS written from the ground up as a multi-threaded C++ API (there
is no C API on BeOS, except for the posix stuff), to NT with the
braindead MFC (as someone once wrote, MFC is a stinky framework to work
with), to being as fast as the current single threaded unix source, then
that will have succeeded in my eyes. I don't have Solaris x86, but if I
work with kernel threads under Linux, I'm sure there are good
approximations for these under Solaris as well.

I take the point that many developers on this list are either too busy
(as it is a major rewrite from even the 1.2 source tree from what I can
see), but to remove the unixisms will be a major pain. If I started on
this project, I'd take the current 1.2 beta and work with it to split up
the core functionality and try to isolate the bits that are OS specific.
If this can be made so that each of the major areas can become
multi-thread safe (they don't HAVE to run in a threaded environment),
that would be excellent.

I've read the papers on why in some cases a multi-threaded version of
squid wouldn't be that much faster, and to a degree I agree with these
positions. We use hardware RAID 5, so effectively trying to read with
multiple threads to the same disks under pressure wouldn't really help.
I bow down to the concerted wisdom of Andres Kroonmaa and John
Ousterhout regarding threading of the current code. In fact, Andres
mentions that a seperate project might be necessary: "It may simply
prove to be too much of rework that a separate project would be
appropriate." I hope not, but I've got a funny feeling! :-)

There was a paper that came across the linux-kernel list a while ago on
multi-threading the TCP and UDP protocols. It found that a start to
finish approach per thread performed best instead of handing off data to
seperate modules. They found that TCP could be sped up by 4x (best
effort) by using this mechanism and UDP by 12x (as long you have
processors to spare). UDP was more easily done because of the lesser
amount of state kept. I'm sure squid (and object caching in general)
fits this model, so that should be the threading model ; a pool of
worker threads servicing incoming requests from start to finish. It
requires all state data to be completely seperate, but it should work
fine.

But as in most projects, I'd be kidding myself if I could completely
re-write this without your help. No ego is that big! :-) If there is
someone working on threading squid for any operating system I'd love to
hear from them. At a SAGE-AU meeting a while ago, one of the bods from
either Access 1 or connect.com.au noted that someone was working on it.
That was more than a year ago, however.

Andrew

> -----Original Message-----
> From: Bill Wichers [SMTP:billw@unix0.waveform.net]
> Sent: Monday, 2 February 1998 4:24
> To: van der Stock, Andrew J
> Cc: 'squid-users@nlanr.net'; 'pmanuel@cindy.fe.up.pt'
> Subject: Re: Is there a Squid port for NT going on?
>
> I have found that many of our clients don't care what OS runs on a box
> that is sold as a "package"... [van der Stock, Andrew J] [snip]
> Perhaps something like this would work for you?
>
> As for coding new Squid stuff, nobody seems to have the time. I would
> love
> to see a multithreaded Squid (UNIX can use multiple processors too!
> :-)
> since I think this might be of benefit on some heavily loaded caches.
> There have been some cache admins who have expressed an interest in
> this,
> but there doens't appear to be enough interest to actually make it
> happen.
> On a UNIX platform, Squid's processor needs don't usually present a
> problem. Time is spent making Squid's disk I/O and connection I/O as
> fast and clean as possible. A LOT of effort is being put into the
> handling
> of object expiration periods (note the nifty new meta-in-object stuff
> in
> the 1.2 beta). I don't have the coding know-how to do much
> multithreading
> work myself, but there might be some others on the list that could
> help
> you.
>
> -Bill
>
>
        [van der Stock, Andrew J] [snip] [lots and lots deleted]
Received on Mon Feb 02 1998 - 01:03:43 MST