Skip to:
Content
Pages
Categories
Search
Top
Bottom

Queries

  • Avatar of mutualdesigns
    MutualDesigns
    Member

    @mutualdesigns

    David, when we enable the BP Groups Hierarchy plugin, about 250 queries are being added to the page. We’re going from 2 second load time to 30 seconds as soon as the plugin is activated. What might be causing this?

Viewing 24 replies - 1 through 24 (of 24 total)
  • Avatar of mutualdesigns
    MutualDesigns
    Member

    @mutualdesigns

    Even on a fresh install of BuddyPress and BP Group Hierarchy, I’m getting 23 additional queries for each group I create. Am I doing something wrong?

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    It’s hard to say without more details of your install, or preferably examples of the queries. While some additional queries are normal (it is checking for parent groups and such), that sounds way overboard.

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    @MutualDesigns – if you’re using BP 1.5 and are willing to try the development version, you should notice a reduction in processing steps, and possibly processing time. Let me know if you get a chance and whether it makes a difference for you!

    Avatar of Shaun MacRae
    Shaun MacRae
    Participant

    @shaunmacrae

    We’ve been struggling for a couple of months with performance of our site, and I just realised today that everything began to degrade when we installed BP Group Hierarchy. I used the P3 plugin profiler and sure enough BP Group Hierarchy is responsible for 67% of our load time. Un-installing it meant that our site load time was instantly reduced from 12 seconds to 4 seconds.

    I would love it if these performance issues could be resolved. I’m not sure I have seen anything else that provides functionality in this way and I’m not sure what we are going to do to manage groups now.

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    I gave P3 a shot, and all I got was an Apache crash… Can you provide details from your P3 run, along with more info on your setup?

    Avatar of Shaun MacRae
    Shaun MacRae
    Participant

    @shaunmacrae

    WordPress Plugin Profile Report
    ===========================================
    Report date: Sun Mar 4, 2012
    Theme name: unknown
    Pages browsed: 14
    Avg. load time: 10.6559 sec
    Number of plugins: 27
    Plugin impact: 96.83% % of load time
    Avg. plugin time: 10.3186 sec
    Avg. core time: 0.1743 sec
    Avg. theme time: 0.0000 sec
    Avg. mem usage: 121.86 MB
    Avg. plugin calls: 138,505
    Avg. db queries : 5838.36
    Margin of error : 0.1631 sec

    Plugin list:
    ===========================================
    P3 (Plugin Performance Profiler) – 0.0082 sec – 0.08%
    Bp Group Control – 0.0128 sec – 0.12%
    Buddypress – 2.9007 sec – 28.11%
    Buddypress Activity Stream Bump To Top – 0.0027 sec – 0.03%
    Buddypress Activity Stream Hashtags – 0.0030 sec – 0.03%
    Buddypress Community Stats – 0.0323 sec – 0.31%
    Buddypress Like – 0.0056 sec – 0.05%
    BuddyPress Mobile – 0.0170 sec – 0.16%
    Fix Facebook Like – 0.0092 sec – 0.09%
    MailChimp Sync – 0.0028 sec – 0.03%
    Page Links To – 0.0228 sec – 0.22%
    WordPress Hashcash – 0.0020 sec – 0.02%
    Infinite SEO – 0.0475 sec – 0.46%
    Wpmudev Updates – 0.0034 sec – 0.03%
    Yet Another Related Posts Plugin – 0.0322 sec – 0.31%
    Bug Library – 0.0344 sec – 0.33%
    Cubepoints Buddypress Integration – 0.0135 sec – 0.13%
    CubePoints – 0.1754 sec – 1.70%
    Invite Anyone – 0.0350 sec – 0.34%
    MarketPress – 0.1244 sec – 1.21%
    Page Link Manager – 0.0182 sec – 0.18%
    Bp Gallery – 0.0612 sec – 0.59%
    Bp Group Hierarchy – 6.7313 sec – 65.24%
    BP Group Email – 0.0014 sec – 0.01%
    Racquet Network – 0.0207 sec – 0.20%
    Buddypress Private Message For Friends Only – 0.0004 sec – 0.00%
    Akismet – 0.0004 sec – 0.00%

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    @shaunmacrae – that’s crazy! These are the first reports I’ve had of big slowdowns, but it’s obviously a big concern.

    Do you happen to have a LOT of groups? Also, can you check out your groups table and confirm that the `parent_id` column and corresponding key exist?

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    I’ve refactored a bunch of the loading and posted a new development version. It appears stable, but I can’t tell whether it’s any faster. You’re welcome to give it a shot, and let me know if you notice any changes!

    Avatar of Shaun MacRae
    Shaun MacRae
    Participant

    @shaunmacrae

    Hi David,

    Sorry for the late response.

    We have 270 groups. Groups table does have a parent-id – fully populated, with an index.

    I’ll try the dev version out now. Where can I get it?

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    Hey Shaun,

    Development version is available at: http://downloads.wordpress.org/plugin/bp-group-hierarchy.zip

    Glad to here there aren’t any table issues! Let me know if you notice an improvement.

    Avatar of Shaun MacRae
    Shaun MacRae
    Participant

    @shaunmacrae

    Bit better, but still too slow :(

    WordPress Plugin Profile Report
    ===========================================
    Report date: Mon Mar 12, 2012
    Theme name: unknown
    Pages browsed: 14
    Avg. load time: 9.1307 sec
    Number of plugins: 30
    Plugin impact: 93.60% % of load time
    Avg. plugin time: 8.5466 sec
    Avg. core time: 0.4194 sec
    Avg. theme time: 0.0000 sec
    Avg. mem usage: 120.59 MB
    Avg. plugin calls: 135,185
    Avg. db queries : 5504.00
    Margin of error : 0.1646 sec

    Plugin list:
    ===========================================
    P3 (Plugin Performance Profiler) – 0.0041 sec – 0.05%
    Akismet – 0.0029 sec – 0.03%
    Bp Gallery – 0.0691 sec – 0.81%
    Bp Group Control – 0.0102 sec – 0.12%
    BP Group Email – 0.0027 sec – 0.03%
    Bp Group Hierarchy – 5.1675 sec – 60.46%
    BP Member Filter – 0.0016 sec – 0.02%
    BuddyPress Tweet Button – 0.0004 sec – 0.01%
    Buddypress – 2.5175 sec – 29.46%
    Bp Custom – 0.0079 sec – 0.09%
    Buddypress Activity Stream Bump To Top – 0.0029 sec – 0.03%
    Buddypress Activity Stream Hashtags – 0.0032 sec – 0.04%
    Buddypress Community Stats – 0.0180 sec – 0.21%
    Buddypress Like – 0.0051 sec – 0.06%
    BuddyPress Mobile – 0.0208 sec – 0.24%
    Buddypress Private Message For Friends Only – 0.0018 sec – 0.02%
    Fix Facebook Like – 0.0083 sec – 0.10%
    MailChimp Sync – 0.0028 sec – 0.03%
    Page Links To – 0.0190 sec – 0.22%
    WordPress Hashcash – 0.0023 sec – 0.03%
    Infinite SEO – 0.0538 sec – 0.63%
    Wpmudev Updates – 0.0088 sec – 0.10%
    Yet Another Related Posts Plugin – 0.0407 sec – 0.48%
    Bug Library – 0.1075 sec – 1.26%
    Cubepoints Buddypress Integration – 0.0137 sec – 0.16%
    CubePoints – 0.2481 sec – 2.90%
    Invite Anyone – 0.0355 sec – 0.42%
    MarketPress – 0.1420 sec – 1.66%
    Page Link Manager – 0.0166 sec – 0.19%
    Racquet Network – 0.0117 sec – 0.14%

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    I’ll keep working on it, but I’m not sure how much can ultimately be done about this.

    Computing the intended group for any request is a database-heavy process, especially when the groups are deeply-nested. Optimization is problematic since there may be any number of valid path segments AFTER the group name.

    That certainly doesn’t mean there isn’t potentially room for improvement, though. :) If anyone has any ideas, I’d be happy to talk them over and/or give them a try!

    Avatar of Shaun MacRae
    Shaun MacRae
    Participant

    @shaunmacrae

    Hi David,

    Does the slow logic need to be performed on every page of our site? Maybe we could only execute it on the groups page or something?

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    lol. What a revolutionary idea! :)

    Page routing does need to run on every BuddyPress page (it hooks `bp_current_action`), but it only runs on the first call, and quits ASAP if the page isn’t a groups page.

    Avatar of Shaun MacRae
    Shaun MacRae
    Participant

    @shaunmacrae

    hmmm … my stats were based on 14 different pages being browsed … possibly none of them the groups page … yet they were all taking 10 sec to load instead of 4 when the plugin is disabled. If the call is exiting asap on non-group pages, why were the page loads so slow? Let me know if I misunderstood. Thanks!

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    If you have doubts about how the plugin handles different pages, I encourage you to take a look at the source yourself.

    I will continue to work on improving the plugin, both in adding new features and optimizing what’s already there. But you don’t seem to have a good sense of which pages are even being “profiled,” let alone what else may be going on with your site, so I don’t have a way to effectively diagnose anything.

    Avatar of Shaun MacRae
    Shaun MacRae
    Participant

    @shaunmacrae

    Thanks David. I do have a very good sense of how the plugin is impacting my site. It is universally slowing down every page load from 3-4 seconds to 10-12 seconds (roughly 3 times). This is every page, including buddypress activity page, back-end wp-admin pages, everything. So I’m guessing your plugin is running some very performance intensive logic every single time any page is loaded (not just for group pages that are related to your plugin as you describe).

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    As you’ve plainly stated, what you have are guesses. I’ve encouraged you to review the code yourself to get a better understanding of how it operates. Ultimately you are responsible for your site, and I cannot help you without a good faith effort on your part to examine what’s actually happening on YOUR site, rather than just some A/B timing and guesses.

    IF you gather some real information and send it along, we can work on improving the plugin for everyone. Unless you do, though, all I can suggest is that you try the development version and see whether it improves your situation.

    Avatar of Shaun MacRae
    Shaun MacRae
    Participant

    @shaunmacrae

    Thanks David. As I mentioned:
    1) I have tried the development version and it only improves performance marginaly. The plugin is still incredibly slow.
    2) The performance issue is for every page of the site, despite you believe it should only be a problem on group pages (early exit for non-group pages).

    I can look at the code and try and find a solution. I think it could be a great plugin and I am happy to contribute if I can.

    Avatar of Shaun MacRae
    Shaun MacRae
    Participant

    @shaunmacrae

    I think it’s back to what the original poster was suggesting. My database is only getting hit with ~75 queries on page load usually, but with BP Group Hierarchy installed it spikes to almost 3000. I’m going to look at the code and see if maybe there is an opportunity to run less queries and do the queries in memory (php) instead. Please let me know if you’ve already explored this option David.

    Avatar of Shaun MacRae
    Shaun MacRae
    Participant

    @shaunmacrae

    Also, confirmed the constructor IS getting invoked for every page on the site.

    I added your blocking code:

    ` /** Abort processing on dashboard pages and when not in groups component */
    if( is_admin() || ! bp_is_groups_component() ) return $current_action;`

    to the constructor and all of my non-group related pages are loading quickly again. Let me know if you think you can incorporate something similar.

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    Which constructor do you mean? There’s more than one class in the plugin.

    If you’re talking about the `BP_Groups_Hierarchy` class, that has to load every time BuddyPress would have loaded the Groups component. If you’re canceling that on non-group pages, you’re going to get weird results.

    If you’re talking about the `BP_Groups_Hierarchy_Extension` class, that’s just a regular group extension and not a very expensive constructor, although it does appear that `bp_register_group_extension` loads on every bp_init..

    As far as extra queries go, I’d love to help but need some more concrete examples.

    Avatar of Shaun MacRae
    Shaun MacRae
    Participant

    @shaunmacrae

    Hi David,

    Yes, cancelling the BP_Groups_Hierarchy construction on non-group pages, means those pages load almost instantly again. With the constructor getting called on a non-group wp-admin page for example, it was slowing the page load from a few seconds to 12+ seconds.

    It’s been a couple of weeks since I made the change and no issues or strange behaviour noted, but maybe we just haven’t found them yet.

    Incorporating this or a similar change seems to be all we need. A reduction in the number of queries on group pages would be nice but we don’t need it bad enough to justify investigating further. As long as non-group pages load quickly (90% of our site), we should be good to go.

    Avatar of David Dean
    David Dean
    Participant

    @ddean

    Hey Shaun,

    Are you SURE it’s the `BP_Groups_Hierarchy` class? I just added a `die()` call at the beginning of the constructor, and admin pages load fine. Which is to be expected, since it isn’t that class is not instantiated unless something group-related asks for it. Can you provide a little more context on where you made your changes?

    Also, just wanted to confirm that you’re using BP 1.5 and the latest version of the plugin. Things were quite different under BP 1.2.

Viewing 24 replies - 1 through 24 (of 24 total)

You must be logged in to reply to this topic.