DBMail just received a huge performance boost: version 2.3.3 released today features a shiny new networking/database core.
The new shared database connection pool drastically reduces the number of database connections (and backend network sockets) required to serve large amounts of concurrent frontend users.
The frontend itself, meanwhile, has been rewritten as an asynchronous event-driven process.
Combined, these changes provide solid fundamentals for a future 2.4.x release series focused on performance and scalability.
Paul wrote to the DBMail list:
It is with great pleasure that I'm announcing the availability of DBMail version 2.3.3, the latest in the 'unstable' development series.
This release is the most invasive rewrite since 2.0.0 was released. The number of changes was quite dramatic. Because of this, and the fact that this is still the 'unstable' development series, you should not use this server in production environments. Please use 2.2.10 there until 2.4.0 is released.
Some of the highlights:
- libevent: the preforking code was removed and DBMail's server code was rewritten around the libevent library. This means each DBMail server will only run as a single process and will automatically use the best kernel facilities available to provide multiplexed connection handling.
- libzdb: the native drivers for MySQL, PostgreSQL and SQLite3 have been replaced by an external library that provides full support for prepared statements and a shared database connection pool.
- threads: the IMAP server uses a worker threadpool to deal with high concurrencies without blocking on database calls. Combined with the shared database connection pool this means you can run hundreds of clients against a single DBMail process while only using a very small number of database connections. While the POP3 server will be made threaded over the next releases, the LMTP and MANAGESIEVE servers will probably remain single-threaded. Neither requires high concurrencies generally and the event-driven server core already provides excellent performance and throughput under low concurrencies.
There is a bug in Thunderbirds IDLE code that makes TB behave erratic. You should disable IDLE in dbmail.conf by tweaking the CAPABILITY setting, or disable IDLE in TB itself by editing the account settings below 'servers...', 'advanced'. I will work around this in the next DBMail release.