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
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
