Re: aio_read implementaion in Squid

Andres Kroonmaa wrote:

> I don't think anyone has any figures or tests done on that matter.

Nod.

> If You think of ultimate performance for squid, eventio will not solve any
> problem actually. If I understand it correct, then its just a framework,
> abstraction layer within Squid that helps in plugging different IO models.

It is a little bit more than just a framework. It is a I/O model where
different notification mechanisms (poll, select, kpoll, and maybe AIO or
completetion ports, ...) can easily be plugged in. The I/O model as such
has implications on the whole data flow within Squid.

> It will make squid much simpler and cleaner, but bottlenecks will stay.
> poll() overhead is not very big, its the way it is used that makes the
> overhead to add up. Ontop of "eventio" new api things can be done better.

Correct.

> When trying to remove all bottlenecks from the path, you'd eventually have
> to eliminate excessive "expensive" paths from equation.
> - syscalls are expensive. You need to reduce number of syscalls/request.
> - memory latency is expensive. Need to increase locality and reduce copy.
> Both are related to either OS or hardware specifics.

The eventio I/O model includes elemination of unneded copying. It goes
not as far as using sendfile() and similar appoaches, only elemination
of all copying within the process.

--
Henrik