Possible Performance Issue Membership Plugin?

Hey guys,

Sorry if I'm wrong, but I have noticed a increase in database queries with each page load and just did some debugging and got a bit of a fright. lol

I see that membership plugin calls the database for bunches of members on each page load. (Either bunches or the entire list of members - not sure?)
It cycles through list of members checking start_current / expire_current / and whether to send the communication emails.
This is only one member out of the list...

SELECT user_id, meta_key, meta_value FROM plus_usermeta WHERE user_id IN (1059)
SELECT * FROM plus_usermeta WHERE user_id = 1059 AND meta_key LIKE 'start_current_%'
SELECT * FROM plus_m_communications WHERE periodstamp >= 0 AND active = 1 ORDER BY periodstamp ASC
SELECT * FROM plus_usermeta WHERE user_id = 1059 AND meta_key LIKE 'expire_current_%'
SELECT * FROM plus_m_communications WHERE periodstamp < 0 AND active = 1 ORDER BY periodstamp ASC

Wow, I'm only testing with a 50 or so, what would happen with a couple of thousand?

Please tell me it is because of my testing environment - lol.
This is on my home pc - using wampserver.

And if it isn't surely the start / expire should run only when individual user logs in. And communications should possibly run on some sort of cron? / or at least an option to deactivate it entirely.

Thanks guys,
Jonathan

  • Jonathan

    Well, I just added a bunch more members and the queries haven't gone any higher... Woot!
    So, it isn't for every member - (breaths a sign of relief) but, it seems to be in batches - which is better, but I haven't been able to figure out how this works yet?

    I also haven't ruled out the possibility that It could be my set-up :wink:

    Lots of code to go through and only 1 set of eyes - laugh.

  • Philip John

    Hiya,

    From a cursory look at the plugin I can't see those DB queries although that doesn't mean it's not the Membership plugin.

    Can you tell me exactly the steps you go through to reproduce this please? I.e. what page you load and whether directly or by following a link and from where.

    Does it happen on every page of your site or only some? Is it happening in the backend or frontend or both?

    Thanks,
    Phil

  • Jonathan

    Hiya Phil,

    From a cursory look at the plugin I can't see those DB queries although that doesn't mean it's not the Membership plugin.

    I'm afraid it is the membership plugin :slight_frown:
    That doesn't mean it's a bad thing - lol. From what I can understand it is stuck transitioning members from a to b and b to c. I say stuck because all members have been transitioned (checked database table)
    So it is checking the database for "Updatedate" (should member level move ???)

    rel_id | user_id etc    startdate           updateddate	        expirydate
     3 | 1053 |2|12|2011-07-28 14:07:32| 2011-08-09 09:20:50| 2011-08-10 09:20:50| 3

    Glad to say the above database entries shows it works - and it should tranisition the above member tomorrow again, but it is still running the check. I count that it various in amount of members it checks, but it is around 25 members at a time.

    Oh yes, Those queries are in the class.membership.php transition_through_subscription function() and class.communication.php
    Still trying to figure it out - lol

    Can you tell me exactly the steps you go through to reproduce this please? I.e. what page you load and whether directly or by following a link and from where.

    Added 50 users on mixed subscriptions A and B each subscription has its own 6 levels. Most of the members on Subscription A and members are in various stages of levels (6 levels in total) finite at 1 day intervals. Last level being indefinite.
    Just added another 50 users to subscription B with various stages of levels (6 levels in total) finite at 1 day intervas. Last level being indefinite.

    Does it happen on every page of your site or only some?

    Any page (home/category/post/page/ etc) is a mix ( 90 - 200 database queries ). It can be 80 on a page load, then 168 the next time.
    Membership plugin deactivated average 28 database queries. That is a huge drop.

    Is it happening in the backend or frontend or both?

    I've only been testing on frontend as that is where traffic will be :wink:
    Oh, This behavior is for both logged in and non-logged in user and even admin.

    I have a hunch. I am using global tables - I had a single install and don't remember this issue.

    Oh, I haven't even started trying to figure out the communication queries. Which is a weird glitch as I don't even have any created. lol

  • Jonathan

    @bigonroad
    I've Checked logs etc - but nothing out of the ordinary and nothing connected to this. My wampserver has been pimped :wink: so it is better than any free / shared hosting account - lol
    And I can do things I would never want to do on my vps(s) :wink:

    What is happening is
    It's as if the 'check' loads on each page load irrelevant of the fact that it has already updated and transferred levels. Also the communication runs irrelevant of the fact that there is no communications present.

    I am pretty familiar with the code itself, been playing around with membership plugin for awhile, but haven't spent any time with the actual level migration and communication. So I am a little lost... will just take time to unravel the sequence.

    But from experince - Moving users from level a to b should happen when that individual user logs in, or on some sort of cron spread over x number of hours. And communications should be disabled if not being used, and if being used should also be on some sort of cron.

    All in all, I am very impressed by @Barry's code - I wish i was half as good. Love the way he structured this whole plugin.

    EDIT:
    Sorry I haven't been able to figure this out yet - lol. My sister-in-law is in labor. My wife happens to be her twin sister. And you know those rumors that the one twin feels what the other goes through... Well it is 100% true - lol. DAMN!

  • Jonathan

    *bump*

    My sister-in-law gave birth to a healthy baby girl - Woot! And my wife has now decided on Cesarean with ours - lol.
    Now that, that is over I have tried re-looking into this with various install setups and it happens on all of them.

    Create membership site with couple subscriptions and multiple finite levels then toss into the mix a whole lot of members on various stages of membership and watch the queries start climbing the more members you add to the mix.

    Good news is that it has a ceiling. And queries haven't climbed over 200 irrelevant of number of users (tested up to 500)

    Also, at least the reads are cheap - memory averages around 25mb to process a wordpress page. With membership plugin deactivated 19mb. And no performance loss with load times.

    This user level upgrade check thingy on each page load is membership plugin related. I've seen this before with wishlist member (nightmare! queries would go up into the 1000's and had the possibility depending on how the end user was using the plugin to cripple a server).

    Anyways, I wish I could fix it, but this is out of my hands.

    Marking this as resolved because it isn't an easy fix situation, and until someone can reproduce this, I am treating it as a specific issue with my setup :wink:

    Jonathan

  • Jonathan

    This sounds like the necessary checks to ensure members are on the right levels at all times but spread out to avoid causing too much of a load on the server.

    Yip, in a nutshell I believe it is... I just haven't been able to figure it all out (the how it works part - lol)

    I'm not sure if there is a better way to do that

    This depends. I personally like the check to happen when user logs in - runs the code and moves levels accordingly. But Barry is the pro, and I'm sure he had good reason to do things the way he did.

    Membership plugins have the ability to become resource hogs - keeping them as lightweight as possible is always a good idea. But that comes at a price (features) - everybody loves features. I think the introduction of the membership plugin's - plugin system is brilliant. Activate only what you need: brilliant!

    Jonathan

  • Jonathan

    Howdy guys,

    Okay, I managed to track down the issue. It's the communications feature. I thought the issue was the level upgrades etc. But those database queries are called in the class.communications.php
    (Funny thing is I don't even use them - haven't even set them up - lol)

    Communications are a nice feature - But it's not worth the extra load - can next release have the ability to switch it off entirely.
    Just disabled them myself - saw a 75% drop in queries - Wow :wink:

    So, I would rather ping mailchimp / or some other option and have them handle the communication side of things.

    As always, open to your ideas regarding this issue.
    Thanks guys.
    Jonathan

  • Jonathan

    @James,

    Thanks for stopping by and taking notice :wink:

    Yip, it'll be great if we can optimize the communication process for better performance.

    Currently I have this as a fix - it just disables the culprit function. Not pretty and not permanent. It's hard to fix without making core changes - But by adding this to a functions.php file or custom plugin network activated depending on setup - it does stop the communications queries from processing on each page load etc.
    remove_action('init', 'M_Communication_process', 10 );

    Thanks again for making Barry aware :wink:

    Jonathan

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.