• Resolved deltaray

    (@deltaray)


    Hi,

    I have found a performance issue when groups plugin is enabled and “SQL_CALC_FOUND_ROWS” in statements like this:

    SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
    FROM wp_posts
    WHERE 1 =1
    AND wp_posts.post_type =  'post'
    AND (
    (
    wp_posts.post_status =  'publish'
    )
    )
    AND wp_posts.ID
    IN (
    
    SELECT ID
    FROM wp_posts
    WHERE ID NOT
    IN (
    
    SELECT post_id
    FROM wp_postmeta
    WHERE wp_postmeta.meta_key =  'groups-groups_read_post'
    )
    UNION ALL SELECT post_id AS ID
    FROM wp_postmeta
    WHERE wp_postmeta.meta_key =  'groups-groups_read_post'
    AND wp_postmeta.meta_value
    IN (
    ''
    )
    )
    ORDER BY wp_posts.post_date DESC
    LIMIT 0 , 16

    Each of these queries take more than a second on a high performance server.
    When I disable the Groups, the problem disappears.

    My database has grown over the last few years, so it might be a following problem of a large database.

    Anybody else expirienced such performance problems?

    https://ww.wp.xz.cn/plugins/groups/

Viewing 4 replies - 1 through 4 (of 4 total)
  • Yes, I am experiencing about 1.5 seconds extra load time with Groups enabled. Latest WP version, all plugins up to date.

    I think it must have grown to become slower as a result of a much larger database over time. That’s not good news if you rapidly want to expand your business…

    When Groups is disabled, 3.0 seconds admin load speed with >30 plugins. When enabled, 4.5 seconds (query monitor info). When enabling three more paid Groups add-ons, it goes to 4.6 seconds but the main issue is Groups.

    This plugin is definitely in need of some serious performance optimization.

    As a workaround, you can try and reduce the front-end impact by selective plugin loading (Plugin Organizer by Jeff Sterup). However, in the back end you can’t help but feel the increasing drag.

    Itthinx, I hope you’ll review the performance aspect of the plugin!

    Thread Starter deltaray

    (@deltaray)

    I think getting “SQL_CALC_FOUND_ROWS” removed from the statement would solve the problem. Because whenever you have “SQL_CALC_FOUND_ROWS” the FULL table will be processed for a statement regardless how many results you want to show.

    I have added some more indexes into my database which got the time for such statements from about 1,5 seconds to 0,5 seconds. Not a final solutiuon but makes thinks better.

    Plugin Author Kento

    (@proaktion)

    SQL_CALC_FOUND_ROWS is added in WP_Query->get_posts() and Groups shouldn’t be removing it, it can’t and really shouldn’t do anything about its presence. If there are any performance issues, then this is usually due to a lack of working cache. There are several previous discussions about this, where an outdated signature of wp_cache_get() is used and the $found disambiguation return parameter cannot be taken advantage of.

    I’ll be looking into actually changing the values stored in cache when an empty result is stored, as there hasn’t been any sign of any improvement coming soon to where that happens. See for example this related topic where I’ve provided an explanation and references http://www.itthinx.com/topic/upgrade-wordpress-core-4-3-2/comment-page-1/#comment-669054

    Plugin Author Kento

    (@proaktion)

    The changes I’ve mentioned are now in version 1.9.0 and the issues with caching mechanisms that do not support the disambiguation parameter $found should now all be resolved. Please let me know if you see any further issues.

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

The topic ‘Performance Issues with GROUPS plugin’ is closed to new replies.