Re: Async I/O on IRIX 6.x?

On Thu, 10 Sep 1998, Henrik Nordstrom wrote:

> Ugh. This does not look right for 40 clients. Far to many outstanding
> requests. 378+804=1182 active files...

Well, those 40 clients are capable of at least 500 req/sec through a
null-proxy.

I have spend a lot of time fixing the async-io stuff on IRIX. I don't want to
put you to sleep with numerous things that have to be changed. However,
one essential problem may be of general interest:

When async-io is working as it should, the disk performance does not
interfere with network performance. This independence was the key reasons for
introducing the async-disk-io, as far as I understand. Network modules are no
longer slowed down by blocking disk IO.

On the other hand, what happens on a loaded proxy with a good network
connectivity? Imagine fast pumping network working side-by-side with a
relatively slow disk... Pretty soon the Squid disk queues exceed any
reasonable limits, while the number of pending open(O_CREATE) requests
continues to grow.

Thus, after fixing the IO code, we got what we wanted -- a very fast Squid.
Unfortunately, that "speed" has to be dealt with. Currently, we monitor the
queues and do not cache objects while the queues are "too long". The
performance of this disk admission control algorithm (as of the async-io code
itself) still leaves a lot of space for improvement, IMO. Working on it.

Alex.

P.S. If you think that x-memory functions (xmalloc, xfree) are MT-safe, think
again. [but their library equivalents (malloc, free) are safe!]. This "bug"
cost me a few hours of debugging perfectly sane code that used xmalloc and
xfree... Just one "word" in all our x-memory routines code makes them unsafe!
Received on Tue Jul 29 2003 - 13:15:53 MDT