[Dovecot] Design: Asynchronous I/O for single/multi-dbox

[Frank Cusack]

On 3/14/10 1:46 PM +0200 Timo Sirainen wrote:
> On 14.3.2010, at 5.27, Frank Cusack wrote:
>
>> On 3/14/10 4:48 AM +0200 Timo Sirainen wrote:
>>> On 14.3.2010, at 4.40, Frank Cusack wrote:
>>>
>>>> Just playing devil's advocate since you haven't presented the advantage
>>>> of async I/O.  I don't want to guess at the reasoning, but e.g. I hope
>>>> you're not planning to return success results before I/O actually
>>>> completes.
>>>
>>> The idea was that a single process could handle tons of connections.
>>
>> And what's the advantage of that?  process-per-client already scales
>> really well, at the expense of more memory.  In both Linux and Solaris,
>> the cost of a process context switch is nearly the same as a thread
>> context switch.  I don't know about *BSD but I imagine it's similar.
>
> Well, you just mentioned the benefits :) Less memory usage, less context
> switches (of any kind). (You aren't assuming I'd do something like one
> thread per connection, right? That's not going to happen.)

But as I stated, dovecot is likely to be I/O limited, not CPU or memory
limited.  Who cares if there is 10% less memory usage when the limit is
still I/O?  Feel free to trout-slap me (to borrow from Stan) if you
expect dovecot to be memory limited.

> That's kind of the point. You could have just a few IMAP processes where
> each can handle hundreds of connections. Currently that's not a very good
> idea, because a single connection that waits on disk I/O blocks all the
> other connections in the same process from doing anything.

Or you could have a whole bunch of IMAP processes, one per connection.
All you're doing is multiplexing the I/O at a different part of your
system.  Each connection doesn't share any state or other data with
other "related" connections so it doesn't matter how you multiplex the
I/O, since any imagined efficiency from AIO/threads isn't going to be
realized due to I/O saturation before CPU saturation.

> Kernel can only parallelize requests from different processes.

Right, but again so what?  Since each connection is a different process,
all I/O is parallelized in dovecot's case.  It works well because
connections aren't related to each other.

-frank