Hi,
one note before you continue reading: I'm not familiar with xdebug yet
- so you may need to
re-verify me findings. also this mail is not a wish to immediately fix some performance-lag, but more some info to the developers/project managers so they can plan correctly :)
because I was interested.. I installed xdebug today [1] so.. I was cleaning up my mailbox and I deleted 200 messages (at once) according to firebug this took ~60 seconds which is quite much...
then I did some tests... after checking xdebug's profiler output I found something strange: there were 745 queries made by rcube_mdb2->query (which calls _query and this calls the real MDB2 stuff...) 745 queries - and I just profiled the click on the delete button (NOTE: the at this point the messages were in folder X and now they were moved to "Trash")
NOTE: there was one huge call to rcube_imap->set_flag() which is because I have $rcmail_config['read_when_deleted'] = TRUE; in my config maybe this can also be optimized (not sure if it can be - but this should have a lower prio) also read_when_deleted s a real performance-killer, I'll try to explain later
small break here: as I had message caching enabled I wanted to check if really all messages were in my (MySQL) DB.. looked fine after like 10 seconds (deleting was still being done by roundcube) I refreshed the phpMyAdmin page... and what was that? now there were less messages in the table than before.. - even if they were just moved to "Trash" now.. I waited some seconds - and the row count started to rise again
let's try to explain so many database queries (NOTE: keep in mind I had read_when_deleted enabled): when user deletes message 1 from mailbox X the following happens:
- $IMAP->set_flag($uids, 'SEEN'); reads and deletes all messages from
the caching table... that already makes 400 queries
- (message being moved through IMAP)
- (message being parsed through IMAP)
- message being inserted into the cache table (in the DB) again - that
makes another 200 queries -> we're at a total of 600 now
plus some others (had no time yet to fully check this)
now.. I'm pretty sure that set_flag kills so much performance because it removes the messages from the cache. wouldn't it be easier to just update the header column in the database? (ok, I see it's needed that you unserialize the field.. change some value, then serialize it again and I'm not sure if that costs even more time) also move_message() should do the same, currently it just gets the mail from the caching table and removes it from there (if it exists) - later it has to be inserted into the DB again
I may do some more tests later.. feel free to suggest other parts which I could profile :)
Regards, Martin
[1] http://www.xdebug.org/docs/ _______________________________________________ List info: http://lists.roundcube.net/dev/