Re: apache style squid?

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii

Hi

> Has anyone given any thought to building an apache style squid?
Yes, but then it wouldn't be squid... The whole idea was to have
a single process (avoids context-switching) that's portable
(doesn't use threads and other fancy tricks) and doesn't fork (avoids the
extra overhead).

Apache has a cache-module... perhaps it's worth spending time on,
rather than re-writing large amounts of squid?

I think that with the advances in OS's lately, a lot of the
above problems/inefficiencies are irrelevant... or they may not be...
Some OS's still have a NASTY context switch time AFAIK...

I know that Dave Miller (one of the linux gurus) was very impressed with
the things squid does to try and optimise it's throughput. If you
compare something like the Zeus web server (http://www.zeus.co.uk/) with
apache there is a major speed difference... (300% supposedly).
Zeus is a single process which (from what I can see from the binary)
forks off as many processes as there are CPU's and then hands off
requests to these single, monolithic programs... if there is only one
CPU (and thus one process) and it starts running short on FD's, it seems
to fork off a seperate process to handle those requests.

> Don't need large amounts of file descriptors per process. Each
> process is only handling 1 request at a time, so if
> it's using more than 15 file descriptors I'd be
> suprised.
Yep - though you could do the following:

Parent - small, forking is cheap.

Parent forks a child immediately on startup. Parent does the select on
the main FD and if it gets a new connection it passes the FD to the child
process. If the child gets low on FDs, the parent forks a second child.

> Some memory management wins in being able to alloc() a bunch
> of private memory, and then exit() the process, having
> the parent re-start you. I.e. guarenteed return of
> memory to the system.
One nice advantage to apache...

> Slightly stiffer porting requirements. (now requires a working
> mmap() implementation, and a decent VM
> system. i.e. real copy-on-write)
This is probably where you are going to run into trouble. If you break
this hurdle then... see the below point.

I think that it's possible to keep the current single-process model and
use some of the nice features that OS's offer (like mmap)...

Oskar

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:43 MDT