I've seen both of these problems too (with DBMail IMAP). It was a significant enough problem that I've decided to stick with Cyrus, at least for now. DBMail also seemed to have problems parsing certain messages that were split on the header/body boundary and inserted into the DB directly. (during test migration.)
I've definitely especially seen the latter problem noted below. I could select a 10MB attachment from MySQL client in seconds, but it would literally take several minutes (sometimes 10 or more) to retrieve it from DBMail IMAP. Mailbox refreshes also seemed to be on the order of two or three times slower than Cyrus for the same mail. One thing that would dramatically increase performance would be to change the db schema; of course, this would be a big operation since dbmail is in production, so I'm actually considering writing yet another IMAP server. 1) separate the message headers (perhaps also parse out the most common ones) into separate fields in the db. this would allow faster sorting and mailbox listing and wouldn't require parsing a full TEXT field just to get a mailbox listing. 2) move all or larger (>32K) message bodies to disk or at least to a separate table. again, this would dramatically enhance performance where indexes might oitherwise get bogged down on inserting and possibly selecting, and probably speed performance on inbox listings etc as well. (especially full text indexes on the message bodies.) (as i said, i'm thinking about taking the existing python imap server code in twisted matrix and writing a new dbmail-server engine around it with pluggable backend message stores. the performance might not be as high (python vs straight c) but the long term maintenance would be better and it'd be easier to optimize.) any chance of optimizing the schema and/or fixing the perf problems here? I really think storing at least a good section of the messages (most of the header, for example) in the db makes a lot of sense, but i think dbmail at the moment isn't optimized as much as it could be. On Mon October 6 2003 1:50 pm, Christian G. Warden wrote: > On Mon, Oct 06, 2003 at 12:48:16PM -0500, Bret Baptist wrote: > > Well I think we can rule out the postgres libs, since I am running MySQL. > > I am thinking it must be the SQL code they are using, instead of idling > > while waiting for the client to download, it is just taking all the cpu. > > I haven't seen the high load cpu usage, but the imap server does seem to > have some problems too. Looking at my mysql logs, I often see it > running the same queries many times in a row while retrieving a message. > For example: > 031006 11:38:15 9331 Query SELECT messageblk FROM messageblks > WHERE message_idnr = 9051 ORDER BY messageblk_idnr 031006 11:38:18 9331 > Query SELECT messageblk FROM messageblks WHERE message_idnr = 9051 > ORDER BY messageblk_idnr 031006 11:45:56 9331 Query SELECT > messageblk FROM messageblks WHERE message_idnr = 9051 ORDER BY > messageblk_idnr > > It is also very slow retreiving large messages (those with multiple > messageblks), sometimes up to 10 minutes for a 2MiB file. The load is > not high during this time, so I'm not sure what it's doing. Notice the > timestamps between the second and third queries above. > I'm using the debian package 1.1.20030726-1. > > xn > _______________________________________________ > Dbmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail
