[andersson]

Anyone who knows if there’s any progress in reducing the append_user_meta/topic_meta query count that sort of goes off the charts in alpha 1.0?

A time table would be much appreciated. Thanks.

[Sam Bauers]

I’m not exactly sure what you mean. There comes a point where we can’t reduce query count any further without resorting to complex joins, and to allow ourselves flexibility we need to avoid those. Caching solutions prefer simple queries and 1.0 has much better caching capabilities thanks to the use of the object cache functions in BackPress.

Also take a look at the WordPress memcached plugin, which is a drop-in replacement for the BackPress object cache functions and class, which hooks into a memcache server.

MySQL query caching should alleviate most speed problems though.

[andersson]

Well then this problem may just be locally for me then, but when running the alpha 1.0, for a topic for instance, runing _CK_’s excellent admin tool you’ll see about 50-60 queries that does something like this:

# 51 : 0.0195 seconds

SELECT * FROM bb_users WHERE ID = '6526'



# 52 : 0.0122 seconds

SELECT meta_key, meta_value FROM bb_usermeta WHERE user_id = '6526' /* WP_Users::append_meta */



# 53 : 0.0004 seconds

SELECT * FROM bb_users WHERE ID = '5605'



# 54 : 0.0003 seconds

SELECT meta_key, meta_value FROM bb_usermeta WHERE user_id = '5605' /* WP_Users::append_meta */



# 55 : 0.0014 seconds

SELECT user_id, meta_key, meta_value FROM bb_usermeta WHERE user_id IN (365,1325,267,1088,2295,1106,94,1259,1225,1210,2230,3055,7,4566,3869,2992,1894,5690,2713,5873,6526,5605) /* WP_Users::append_meta */

As you can see, it has run over 50 queries that simply does what is done correctly in query 55 (the last query). It seems it runs this for every post it displays (I display 30 posts per page).

Like I said, maybe this is something that is just happening for me but I seem to remember someone having this problem with the first page also, but that time it was the topic meta I think.

Any help is much appreciated.

[Sam Bauers]

I’ve pinpointed and fixed that particular issue on topic pages in trunk. You should only get a query equivalent to number 55 in your query set for adding meta data, but the individual user queries will remain. Still, that will help a lot on that particular page.

[Sam Bauers]

Relevant change is here:

http://backpress.automattic.com/changeset/160

[Sam Bauers]

Topic meta is similarly arranged to do less queries. I think the problem that was cited was that sticky topics and normal topics were not done in the same query. We decided against changing that in the end I think.

[andersson]

Well, I just updated from the trunk and I of course think this is a superb forum and the job you do is great and all that, but 80 queries in the topic overview page of my forums, 47 queries on the frontpage. That’s a tad too many.

Are you, or are you not, looking into this in the future i.e. before the release? Thanks.

[frooyo]

@sambauers & @andersson

I believe I have a simple but highly effective fix.

Since the vast majority of forum traffic is for non-logged in user AND, since the only time a forum page changes is if a POST is made … why not implement a very basic disk caching system that does the following pseudo code:

// Front page

---

if (not logged in)

…….. serve disk cache

…………….if (disk cache not present)

……………………generate page and save to disk

else

……..generate page (PHP)

// Topic page

---

if (not logged in)

……..serve disk cache

……..if (disk cache not present)

…………….generate page and save to disk

else

……..generate page (PHP)

// post a comment function

---

delete Topic cache for non-logged in users

delete Front page cache for non-logged in users

The benefit being, now for any non-logged in user – the Front page and individual Topic pages will be cached once some submits a new comment.

And if you are logged in, non of this effects you.