On 08/15/2011 12:16 PM, Robin Horforth wrote:
> I'll try PostgreSQL 9.0.x next. My preliminary tests show it to be
> much faster on these sorts of operations.
Very interesting! Keep us posted.
>> 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).
That would make sense. APPEND is fully threaded, and should quickly
saturate the connection pool. Check and tune max_db_connections in
dbmail.conf to find the sweet spot for the backend server used. But I
have no experience with how this would scale for this particular scenario.
>
>> 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.
Indeed. Looks like search is broken. I think there's already a bugreport
for that on the tracker.
That said: SEARCH TEXT is done very poorly at the moment: no FTI, full
table scans using HAVING LIKE queries. FTI is sorely needed here.
> When I alter the search to use "FROM" as the key instead of "TEXT",
> the results are more discriminating and meet expectations.
Ok.
>
> OK, so MySQL isn't the fastest writer in the toolbox, but I expected
> a bit more from it on searches.
Blame me.
--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin
* Premium Hosting Services and Web Application Consultancy *
www.nfg.nl/[email protected]/+31.85.877.99.97
________________________________________________________________
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
