Caching in bbPress?
Looking in the code, I see a lot of references to object caching, but I don’t think it’s actually used anywhere.
Does anybody know the state of the caching system, or what the problems were that required disabling it? Will it ever be enabled again?
And yes, I already posted to the mailing list quite a while ago and got nothing.
bbpress uses so few queries that caching has got to be a low priority, especially when the point of a forum is to have very dynamic updates customised for the logged in member – it’s very different than a wordpress environment
as long as you have the mysql cache turned on, it should be very responsive – just look at the main wordpress support forum – eaccelerator would take care of caching the php opcode and that can’t be too far behind a static page
the bonus is that on an active forum, everything will be very dynamic as it happens…
I’m using xcache and mysql query caching with quite a bit of memory assigned to each, I just don’t like going to the database unless there’s an actual need for it.
Few queries? That doesn’t seem right. If you are logged in, the amount of queries is ridiculous, especially if you are using plugins.
I’ve hacked most of the plugins to make them more efficient, but a topic with 5 posts is doing 20 queries or so.
Right now, it’s not a big deal since my forum isn’t even doing 1k pageviews/day, but I’m planning ahead for growth, and would like to have some type of caching somewhere.
There is soft user/topic caching, but there’s no hard caching yet. If you look at the code, in cache.php, you’ll see that it’s written to enable file-based caching in bb-cache/, but doesn’t seem to do so at the moment. It probably will in future I guess? If you fiddle you could probably turn it on. mdawaffe is now working on xml-rpc when he’s working on bb at all, so it’s not the next feature at least. I also think he was planning something else for .8.4.
Would you mind sharing the work you did to optimise the plugins, I’d be interested if any of them are ones I take care of?
I’ve been posting my optimizations into each of the official forum threads for the plugins… I’m not sure if any of yours were affected or not… can’t remember at this point.
How do you handle caching a page with items only a moderator should see, and then pages that are okay for subscribers, and then pages that are for open public? The cache will have to be rather smart. And then you can’t show any personal information on the page like the user’s name if it’s going to be cached.
bbpress still has some non-optimised routines that don’t use the soft cache, for example on the topic page, I’ve noticed it does a query at the end to fetch all the forums names for the moderator “move this topic” tool. Those should definitely be in the cache but it’s not used.
For a logged out user, I have my topic pages down to 15 queries. That’s the most “expensive page”. It uses 3 more queries for a logged in user (one of them listed above).
But I’ve got this geoip flag function that I wrote to show country flags and unfortunately it’s very “expensive” and adds an extra query for every unique poster on the topic page. There’s no way to stack requests since it must search by range (researched it like crazy but no solutions). I have to eventually code it to store the country data in the usermeta. But there’s the issue that their IP/location can change on a per-post basis and that sometimes I have to patch the geo information because the db gets it wrong. Oh well.
From what I remember the inbuilt cache in bbPress (when turned on) is just an optimised list of topics, posts, forums etc. Not entire pages of html.
MySQL caching is definitely a good idea. I’ve had trouble with eAccelerator in the past though – it used to munge multi-dimensional session data (can’t say if that’s still the case, or if it is a problem for bbPress).
> I have to eventually code it to store the country data in the usermeta. But there’s the issue that their IP/location can change on a per-post basis
An upcoming feature is post tagging, you’ll be able to store this data in an “invisible” post tag I believe.
I’m using xcache with very good luck for wordpress, wordpress mu and bbpress on the same server. Also using mysql caching with very good success.
On a forum, the cache probably shouldn’t be the entire page, but rather sections of it or at least the more expensive queries. A visitor who isn’t logged in should probably see an almost completely cached version of the page.
wp-cache2 for wordpress seems to handle this pretty well, and the built-in caching in wordpress mu also seems to work quite well.
Oh I didn’t realize xcache is just an opcode cache. I already use eaccelerator which seems to have zero quirks compared to other solutions. But yeah, any opcode cache for wordpress/bbpress is a must for any active site.
I already create the sidebar statically across my sites, saves a lot of work and repetition on the db.
the wp-cache “plugin” has flaws in it’s logic. I noticed that unregistered visitors were getting edit links on posts, not good, even if they couldn’t actually edit. Then it has an exclude feature to keep certain parts dynamic, but you can’t have wordpress calls in those dynamic parts because wordpress isn’t actually loaded, which is the whole point. so it won’t work and gives error (#1 confusion to most people trying to use it)
In the end, I hacked wp-cache to only cache the RSS feeds which were causing the most requests, yet the most static of all the content. Caching rss feeds on bbpress should be an easy, useful thing too, but then on a forum I highly doubt the use of rss feeds on anything but the latest discussions.
What really worries me about the 0.84 release is the xml-rpc pingbacks. bbpress is going to become known as the spammers forum of choice with a bad rep, until novices are given an easy option to turn it off, or better yet it’s off by default. I cannot disagree more highly with the entire feature idea. It defeats the entire purpose of a forum. What they are trying to do is have a universal way to cross post across forums but the whole point of a forum is *community* and getting people to actually visit, not stay away.
What they really should do instead of pingbacks if they want easy cross communication, is have a universal login based on a database at wordpress.com – Basically anyone with a wordpress account could visit your wordpress or bbpress site and instantly post if they wanted as “wp.membername” without having to register again and again. Sure there are security issues to be tackled but it’s better than anonymous spam heaven on pingbacks. Akismet won’t protect pingbacks, I see spam in my wordpress.com account every week.
We are in perfect sync on that one… having xml-rpc pingbacks in a forum is the most worthless feature idea to ever be thought of. I’ve completely disabled them on wordpress because I don’t think they provide any true value to the reader, and most of them are spam anyway. I’ve written my own simple spam plugin to run in conjunction with Akismet because I was unsatisfied with what I was getting.
Your idea of the wordpress logins would work if they implemented OpenID in bbPress and had wordpress.com as an openid server. Would actually be a killer feature, I’d think.
I’ve hacked up my wp-cache2 to allow for more dynamic code to be called on each post. Most of my content is really very static, so I don’t need it to be updated often.
I’ve never had any issues with it caching the wrong versions though.
I solved all spam on my blogs quite easily – any post with more than one url never gets approved, never displayed. I’ve yet to see spammers not be greedy and only post one url.
I had forgotten about the OpenID standard! We need to try to suggest that to the right people making WP/BB. That would be one of the most useful features ever (wordpress.com has nearly a quarter million registered members!)
update: WAIT! It’s been done?!?!?
How do we get openid support into bbpress then?!
added: here’s a wordpress plugin to allow openid, now we need to port it to bbpress…
I’ll start a new topic on this…
- You must be logged in to reply to this topic.