> I don't think reading the raw mbox files will pose much of a bottleneck.
I know, I just wanted to reduce that to near zero impact from run to run. > Mysqld will never show more than one worker process. It's > multi-threaded, not forking. mysqladmin processlist should be more > informative. Gotcha. I'll try PostgreSQL 9.0.x next. My preliminary tests show it to be much faster on these sorts of operations. > Doubtful. Again, the low system load seems to indicate low concurrency. > Message insertion is quite intensive on the database. Lots of inserts > going on on multiple tables. Understood. Would I be correct in assuming that having one or more simultaneous APPEND processes running at the same time would show more effective messages/second mailbox insertion performance? I'm happy to extend this to 2, 4, 8, 100 APPEND processes, if it would expose different performance limitations (in ANY of my tested products). > I do all development on ubuntu desktops. Main servers run debian. But I > don't think it should matter. I'll try the bare iron tests on Debian then. Incidentally, the IMAP SEARCH TEXT results using dbmail+mysql are a bit odd. Searching INBOX #msgs = 24714 [NOFIND] Time=2.072423, matches=24714 <--- this should be zero *BUG* [date] Time=2.07519, matches=24714 <--- this is correct [here] Time=2.072075, matches=24714 <--- this should be about 30% of total # of msgs *BUG* Does dbmail break IMAP SEARCH TEXT (i.e., search both body + headers)? Is this a result of relying on MySQL's search algorithms in text-like fields? I'm still puzzled, because I can't believe that 'here' appears in EVERY email. It looks like dbmail's returning EVERY email on a SEARCH TEXT. This is not correct operation. When I alter the search to use "FROM" as the key instead of "TEXT", the results are more discriminating and meet expectations. Searching INBOX #msgs = 24714 [NOFIND] Time=2.161049, matches=0 [james] Time=2.273255, matches=1049 [here] Time=2.165406, matches=2 Not that it matters, but it's much slower than Dovecot's fts_squat for substring searches. Dovecot's fts_squat IMAP SEARCH TEXT results are: Searching INBOX #msgs = 55731 [Updating Index] Time=78.184637 (66% of the mailbox unindexed at start) [NOFIND] Time=0.045654, matches=0 [date] Time=0.13364, matches=55731 [here] Time=0.069091, matches=24663 The matched sets are correct, incidentally. OK, so MySQL isn't the fastest writer in the toolbox, but I expected a bit more from it on searches. =R= _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
