Jesse Norell wrote: > There have been some changes to improve speed since 2.2.2 though, > haven't there?
Yes, but those changes affect only retrievals (FETCH) that touch a large amount of messages. Before (<= 2.2.4) a command like A01 UID FETCH 1:* (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type)]) which is what Thunderbird uses to fetch the header information for messages while opening a mailbox, whould retrieve all requested headers and envelopes for all messages involved in one single query before sending this information to the mailclient. While this is ideal for creating maximum throughput during the send phase, it created problems for the clients. Retrieving the potentially very large result sets would simply take too long for large mailboxes. This meant the performance degraded linear to the mailbox size involved and clients would start to time out waiting for results. I've changed this setup for header and envelope retrieval. Now the queries run in batches, retrieving the required information only for a limited number of messages per query (500). And while throughput suffers a bit because of this, the latency that occured before while waiting for the query results is now practically gone. > From irc conversation, another pertinent question is, is > 2.2 svn stable right now? I know there were a run of issues a week or > two back, but have the major issues cleared? If so, Eric could probably > try latest svn and report back on speed differences. Those issues have been all but resolved as far as I can tell. Sometimes messages keep staying at status unread in thunderbird and that needs to be resolved, and I've also suspect that outlook still suffers the 'message UID has changed' problem (I can't find the bug report for this one) that has bugged dbmail already since way back when. I did do some small changes that may affect this particular bug though. The UIDNEXT values is determined slightly differently to match the RFC requirements better, and no EXPUNGE messages are sent in response to FETCH commands. That last one was done to accomodate a outlook express bug that was uncovered by the Dovecot team. So every one who cares is kindly invited to test the stable branch with outlook office if they can, and report back. > > Jesse > > > On Wed, 2007-04-04 at 20:33 +0000, Aaron Stone wrote: >> That's not DBMail being slow, it's your database. Run top during message >> delivery and you'll see who's eating the cpu. Most likely you need to >> vacuum/optimize/analyze your tables. dbmail-util -c will do this for you. >> >> Aaron >> >> On Wed, Apr 4, 2007, Eric Hiller <[EMAIL PROTECTED]> said: >> >>> I have been running 2.2.2 and it has been very stable. Ran it as soon as >>> it >>> came out and it worked on a test machine. Only thing is it is MUCH slower >>> than 2.0.10. Any mail request and the sql server cpu is pegged at 100% for >>> 2+ seconds. Is this issue resolved, or will it be in 2.2.5? >>> >>> Thanks much for dbmail it really has been great, >>> Eric > -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
