Aaron Stone wrote:
> http://monkey.org
/~provos/libevent/
>
> Memcache has incredible performance based on this
library, with all O(1)
> operations behind it. I would like to use a similar
architecture for
> handling incoming commands, then farming out the
command responses to
> threads. Parsing the first 10 - 20 bytes of a command
should allow us to
> whittle down to a single function that responds to that
command. The
> function will be called in its own thread and the main
thread will go on
> to process the next 10 - 20 incoming bytes on another
connection.
This all sounds interesting, however I should point out that
from a
quick read of the page you reference above, libevent doesn't
require
threads.
As for the design, are you planning on making memcached a
requirement
for DBMail? Or just an optional way to make things faster
if need be?
> Also, if each thread only asks for a database handle if
it needs one, we
> should be able to economize on those connections.
Further, if we
> leverage memcache, certain operations should become
extremely fast. For
> example, if each time a message is delivered,
dbmail-lmtpd or
> dbmail-smtp updates the user's mailbox status in
memcache, the next time
> they poll (or, better yet, IDLE) for status updates, no
database handle
> will be needed and the information will come directly
from memory.
The memcached stuff sounds very interesting, and like a very
good idea
to help DBMail scale up, but again, this isn't a reason for
threading,
this looks like it will work fine in a multi-process
environment, and it
looks straightforward enough that we can probably gain a lot
without
re-engineering most of DBMail.
_______________________________________________
DBmail mailing list
DBmail dbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail
|