This depends on where you are calling the query and what other information might be available inside of that loop or template tag.
If you’re calling that function for each author every time something happens then for each unique author it is hitting the DB with another query, and in my opinion that’s always something to worry about.
Thanks JJJ. Let’s use a forum topic page as a specific example. For each post in the thread I will call get_userdata() at least once.
Is there another way I can access each post author’s user_login?
Burt Adsit made a plugin called bpGroups that was able to consolidate the essential user data, but with recent changes to XMLRPC, BP, and bbPress, my guess is that plugin no longer works as expected.
To be honest, WordPress has never really been “light” if you know what I mean, at least not like bbPress is. If you’re using the BuddyPress Group Forums, then you probably have a lot of userdata already available from previous queries in the loop. If you’re using bbPress only and trying to get specific userdata or xprofile data, that’s going to usually require some expensive queries to pull off; I would look at how bbPress already does it with userdata per post, and see how it’s able to to do it. Chances are it’s already been called or that the userdata has already been grabbed previously. If you don’t use an IDE like netbeans to trace variable values, then try a print_r or var_dump of the user variable in the loop, and see what it gives you.
Not only you Reboot, but the entire Buddypress team should be “worried about too many db queries”. Jacoby says that “WordPress has never been light”, I wonder what he thinks of Buddypress, since WPMU creates a page in about 28 queries and Buddypress needs 130 queries per page, about FOUR TIMES as many. It’s completely excessive and makes Buddypress unusable for anybody with any serious traffic and a low hosting budget. Performance (not features) should be the priority now, and the number of queries should be shown along with page generation time on testbp.org so that potential users see the kind of computing power they will need.
This post is two months old.
That aside. I know a couple of guys on IRC have been tracking a few SQL number-of-query issues down which apparently need to be fixed in the WordPress core. Your post is not very constructive as you haven’t suggested a particular page on a site which interested developers could look into – saying that the entire thing needs attention may be valid, but we need to start from somewhere.
@Bolonki, I’m going to play devils advocate for a second and probably take the wrong side of this conversation, but the problem with query reduction in a social networking platform is that the only way to do it is to limit the available run-time data, or rearrange data structures to the point where other plugins can’t tap into them or repurpose them.
BuddyPress itself is a core set of 9 plugins, an abstraction layer for WPMU blogs, an API for bbPress, and comes with an elaborate set of functions and API to retrieve that data and use it in a theme; and most of this is accessible on almost every page of your website. If you need the functionality that BuddyPress provides, then hopefully you’re prepared for the overhead it takes to have all of those resources available. If you don’t need parts of it, you can turn them off and reduce queries.
This isn’t to say that BuddyPress doesn’t strive to be efficient, and in future versions you can bet that as more people become actively involved in the project that it will only get better.
Everyone has parts of web development that they’re passionate about. Some people dig SEO, some love web standards, others are worried about queries, and others are worried about server speed. There’s a lot of roles and lots of talent paying attention to all of the different aspects of what makes this all work. Remember that this is an open project, and we welcome you or anyone else to take a look at ways to make the platform better and are genuinely excited for anyone to contribute in any way.
I’m curious how many queries other social network sites use on a single page load. Can you imagine how many servers Facebook must use? Or wordpress.com? Must be pretty intense to manage all that data and traffic.
@Jacoby who wrote “I’m curious how many queries other social network sites use on a single page load.”
I was too, and saw that it varies widely — from about 40 queries per page for the commercial SocialEngine script (which now includes Zend fragment and full page caching, very nice) to the mind-blowing 1.364 queries just to show the Dashboard on Elgg as reported in Elgg’s own forum. As for Drupal, it makes a similar number of queries per page as BuddyPress (of course it depends on the number of modules, etc) and with that level it is such a mess that Jesse Farmer, the main developer for Popsugar (the most trafficked social network built on Drupal) abandoned the project and wrote on a developers forum that Drupal is impossible to scale and “it would have been easier to start from scratch”. And bear in mind that Popsugar got $5 million from Sequoia Capital, so they have plenty of money to “throw hardware” at the problem.
@DJPaul, who said “Your post is not very constructive as you haven’t suggested a particular page on a site which interested developers could look into – saying that the entire thing needs attention may be valid, but we need to start from somewhere.”
I am not a coder, so how about starting here: I will pay $500 dollars to the person or team that reduces the number of queries on the main Buddypress blog page to around 20 (which is the normal number for a WordPress blog running the default theme). I am ready to escrow this money on the site of their preference.
DB Cache and WP Super Cache could help, not sure if they work with WPMU + BP.
And even if they would, you have 2 make sure that they wont cache member pages or active topics.
