On Wed, 2007-01-31 at 17:13 -0500, Matthew T. O'Connor wrote: > Paul J Stevens wrote:
> > Another goal is scaling up the number of concurrent connected clients > > without depleting the database connections. Using connection pools is a > > best practice there, and even though that could be done in a > > multi-process architecture, this is generally done using threads. > > I don't see how this makes things better, what it sounds like you are > suggesting is that DBMail will become in addition to an IMAP server, a > database connection pooling engine. There are tools out there that do > this already. 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 is the reactor/proactor pattern (they are subtly different, and we might want to blend them a little bit) and after lots of reading, its what I think we should be doing next. 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. Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
