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.)
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.
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.
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.
Kernel can only parallelize requests from different processes. But AIO allows for example telling kernel that:
- open files 1..10
- read contents of files 1..10
rather than:
- open file 1
- read contents of file 1
- open file 2
- read contents of file 2
- ..etc..
All of this when processing a single client connection's command(s). And while waiting for I/O replies Dovecot can do other work. So user sees results earlier.