Re: async-io network / future Squid design

Joe Cooper wrote:

> With some speed improvements I hope? The signaled async network stuff
> Nikita posted a few days back was cool but quite slow in it's then
> current state. Has that been addressed? (Or was the problem between
> the chair and the keyboard? i.e. Mistakes in configuration on my part?)

I don't see the point of async-io network. It already is asyncronous via
the TCP socket buffers (which is related to but not limited to the TCP
window) and non-blocking I/O.

What might be needed is to address the CPU overhead of poll(). When you
have a large number of connections poll() becomes a CPU hog (not as bad
as select() was, but still..).

There has been quite extensive discussions on what the networking I/O
model in Squid should look like, and the current design is far from
optimal in many respects. Unfortunately things has not been moving along
as quick as one might hope in that area. The discussion also needs to be
carried little further to find the wanted design.

What I would like to see from the kernel side is a better alternative to
poll where you instead of polling each and every filedescriptor get back
those that are ready when they are, and a quick indication on how ready
the socket is (amount of data that can be read/written there)

From the Squid side I would like to have a major redesign within the
next half year to

a) Make I/O demand driven rather than polled. The deferred reads should
be a sideeffect of the I/O pattern rather than a requirement for proper
operation. If we know that a client connection is waiting for data then
schedule reads from the server, and when data arrives write it to the
client. (the senario gets slightly reversed when the forwarding gets
client bound, and with a few tricks to detect aborted connections)

b) Have memory buffers allocated when the data is created, not when it
is requested, and do not copy the data unless required for alignment.

c) Change the request forwarding to fully center around a request rather
than have a StoreEntry in the center. The store can tap data pages from
the request forwarding or feed data there, but is should not take an
active part in the data forwarding. (also note change b above..)

d) Each cache_dir should be self contained, responsible for it's own
index of the content. The storetree approach is a partial exaple of
this; the same idea, but lacking the changes above to make it clean.

On my agenda I also have ideas on how to remodel Squid to make use of
SMP systems. The storetree idea has revised these thoughts somewhat as
it makes life a lot easier not having to worry about the store index.

/Henrik
Received on Sat Sep 16 2000 - 10:41:56 MDT