Re: [squid-users] Epoll and COSS on a lightly-loaded server?

From: Domingos Parra Novo <domingosnovo@dont-contact.us>
Date: Wed, 09 Aug 2006 14:32:05 -0300

        Hiyas Steve,

Steve Snyder wrote:
> What do the new epoll and COSS options offer to me as the administrator of
> a lightly-loaded Squid server? Anything?

        On a "lightly-loaded" server, not much. It will help scale the use of
this server (giving the possibility of handling more users with the same
hardware). If this is not an issue for you, there's no need to worry
right now.

> I usually read of epoll in the context of being recommended for a Squid
> server with very high CPU utilization. I'm not clear on the advantages
> of COSS over other disk storage schemes.

        Unix daemons (squid included) usually calls poll() or select() to
handle file descriptors. Specifically to squid, it will mean how much
users your machine is able to handle.

        The use of poll() by itself is not a problem. It starts to be a an
issue when your process (squid) needs to handle hundreds of file
descritors at the same time, as it will use more and more processor time.

        In the other hand, epoll() is a newer interface to handle file
descriptors (specific to Linux, using kernel 2.6). It is way smarter
then poll() or select(), as it uses less resources then both syscalls,
and scales better. Processes using epoll() will be able to open more FDs
at the same time (using less processor power for that), when comparing
to poll() or select().

        Surelly Chad (or someone else) will correct me if I'm wrong, but COSS
is a different aproach to storing objects on a disk cache. It is not
just meant to be "faster" then ufs, aufs or diskd, but, "smarter".
Basically talking, it tries to create a "raw device" (be it a real disk
partition or a simple file), and store all cache objects on this device.
Objects will then be stored/retrieved in a faster/lighter/smarter way
then other cache mechanisms.

        Unfortunatelly, COSS is not quite stable as ufs/aufs/diskd. And if I'm
not wrong, is not recommended for production use (yet). Of course, the
squid developers will be really glad to find another beta tester for
this item.

> I am currently using UFS on a single ReiserFS-formatted cache, on Linux.
> This setup is working fine, but I am always looking for improvement.
> (Given that I do not suffer from high CPU use, improvement would be
> defined as reduced latency in cache look-ups.)
>
> Any thoughts on what these new option might mean for a lightly-loaded
> server?

        If I was you, I would use squid 2.6stable2, reiserfs (with the options
"noatime,notail"), and "aufs" as the storage system. Also, if you're
using kernel 2.6 on your linux machine, epoll() would be a fine option
to use too.

        COSS would be real fine for a devel or test machine, or if you feel the
need to help testing (and mature) it.

> Thanks.

Regards,

Domingos.

-- 
Domingos Parra Novo
Coordenador de Projetos
Terra Networks Brasil S/A
Tel: +55(51)3284-4275
Received on Wed Aug 09 2006 - 11:32:12 MDT

This archive was generated by hypermail pre-2.1.9 : Fri Sep 01 2006 - 12:00:02 MDT