Well I don’t know if this a bug or not, but I found (almost) the root of the problem and a relatively simple fix.
I discovered that the recipients table had entries for threads that were not in the messages tables. I don’t know where these threads came from, but they were definitely there. So I changed the messaging code to generate the thread_id from the recipients table rather than the messages table.
If this was some sort of database corruption, this was a reasonable fix for me. We don’t have enough messages for it to be a performance issue and if something else is inserting into that recipients table we shouldn’t conflict with it (assuming it is generating thread_ids in the same way).
I really don’t know enough about BuddyPress to know if this is a core bug or some other issue related to our theme (I can’t find any other references to that table so it’s kinda wierd).
bp-messages-classes.php:
/* If we have no thread_id then this is the first message of a new thread. */
if ( empty( $this->thread_id ) ) {
$this->thread_id = (int)$wpdb->get_var( $wpdb->prepare( “SELECT MAX(thread_id) FROM {$bp->messages->table_name_recipients}” ) ) + 1;
$new_thread = true;
}
I’m seeing this as well, and I’ve even seen it happen when our caching system was turned off. Could you provide a few more details as to what modules are involved or how the file caching triggers this as I would definitely like to find a way of fixing this.
I’m seeing this type of performance as well — except that it varies greatly for no apparent reason. It seems to be running relatively fine and then go into spats of incredibly slow response times (sometimes in the 20 second range for a page that normally takes 2 seconds to render.)
