Speaking soley about 2.0CVS-Current
There could be a minor glitch with the icfetch_speedup pertaining to
MySQL. I noticed this after about ten hours. Traffic light, dept. int.
mail server, 128 accounts. The error seems to occur when the
messageblocks on a multipart physmessage_id contains a binary (actually
a screenshot with comments) plus text, plus header. Messages with just
binary, no prob. Well. I am suspicious a litle too about the fetch count
change (nervous Nelly) so scrutiny is real close and might be seeing
things. ...I will do more extensive work, but for sure rebuilding back
to STABLE with the imapcommands.c.orig (4xfetch) makes problem go away.
May I suggest, Mikhail, that I work in whatever else (patches) you have
there and do so some testing for you, if that would help. I did not run
across your db_header_speedup patch but did patch for dbmysql.c.patch
and the icfetch.
dbmysql.c is a keeper - straight forward. 12-hour performance is
trending in the right direction. Bravo.
Mikhail you rock! Nice work. Could you please send me the
db_header_speedup patch (or link) and if you have any testing tools,
criteria or measurement standard you would like to have used, I am
supposed to get a piece of iron pushed back to me here tomorrow from
another project, a week early. I can swap in a BSD drive and have the
thing for a WEEK. of DbMail testing. If not now, the offer stands
whenever I can.
LIST NOTE: Did I miss it or is the issue resolved with 2.0CVS-Current
NOT resetting 'status to 001' on 'deleted_flag=1'?
best...
Mike
Mikhail Ramendik wrote:
Matthew T. O'Connor wrote:
dbmail 2.0+dbmysql: 128
2.0+dbmysql+icfetch_speedup: 184
2.0+dbmysql+icfetch_speedup+db_header_speedup: 193
I'm still very skeptical of making changes to is_fetch in the 2.0.x
branch. I'm all for putting these in 2.1. Anyone else have any
thoughts on the invasiveness of these patches and adding them to 2.0?
Well, I tried to make the invasiveness as little as possible; and there
is a check that falls back to the old behavior in case of anything
unexpected. So I feel this code could be for 2.0.x, but of course let's
wait for independent review.
For 2.1 I'm planning a bigger change, although I'm not yet sure it will
work out in the current code framework. I also have an idea for a SEARCH
speedup in 2.1.
Yours, Mikhail Ramendik
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
