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

[Frank Cusack]

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.

There is a distinct disadvantage in complexity.

> Maybe in the end the number of IMAP processes you'd have would be about
> 1-2 x the number of CPU cores.

I'd think many more than that (regardless of client model - multithread,
AIO or PPC), since most time is spent with the user idle and the IMAP
connection doing nothing.  I'd guess (a) you should be able to support at
least 100 simultaneous clients per CPU, if not 500, and (b) that simul
client support is I/O limited, not CPU limited.

I haven't ever run dovecot with a large user base so I don't have any
empirical data to back up that guess.  Folks here on the list must though.

> And not just that. Also parallelism. Dovecot could issue a lot of I/O
> requests in parallel and OS can reorder those so that it gives the best
> performance by reading them from disk in the right order. And the higher
> the latency to disks is, the higher benefits there comes from parallelism
> (NFS, NoSQL).

The kernel already does that regardless of server implementation.

-frank