The database(s) we're talking about here are the mboxlist, the deliver database, the tls_session database. In general, the mboxlist one is the one that causes people the most problems. It is read intensive. Forcing IPC for each read operation for the mboxlist will not improve server throughput. While forcing write operations through a seperate process would be acceptable, it still means that the inter-process synchronization problems have to be taken care of.
I guess I'd need more details of what you're proposing before I can truly evaluate it. Larry Date: Wed, 06 Feb 2002 18:39:39 +0000 From: Nuno Silva <[EMAIL PROTECTED]> A couple of mounths back someone contributed the (IMHO great) idea of implementing a daemon that takes care of updating the database assync. This as several advantages: - abstraction layer between the main programs and the DB; - easy of writing new DB plugins (skiplist, mysql, berkeleyDB, ...); - *very high* response time for write operations; - the daemon can optimize the writes to the DB; - the daemon keeps a WAL (log) of to-do operations, so the layer is reliable in terms of replies to the main program and writes to the DB; - simple communication "dialect" between the main program and the daemon. Do you have some thoughts about this that i'm overlooking? For big installations this seems to be the perfect (?) answer :)
