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/
