Corey

@missveronicatv we are nearing launching the website; has there been any fixes to this? It is still bogging down the admin side.

Thanks!

@missveronicatv the website isn’t live yet, so I haven’t tested the user approval yet, I am guessing** I could just up the cache number so it never goes below the total number of users — which would solve this temporarily until a solution exists!

Thank you for working on a solution ????

@missveronicatv perfect! That is what I was missing, as we imported all of the fields manually, (it was a merge from Drupal & WP to a new WP) the wp_options table was overlooked and that setting was missed.

I was able to do a SELECT and do a count of all of the users that had a metakey account_status.

I added that number (220,224) to the wm_users_cache_queue and things instantly changed and are running significantly faster now.

Thank you for your help!

• This reply was modified 3 years, 9 months ago by Corey.

@missveronicatv Yep! But is there a way we can disable this SQL query all together on the admin page without hacking Ultimate Member?

@champsupertramp sorry, I meant it was already set up — no change in performance with the indexes.

@champsupertramp yep!

Keyname		Unique		Column			Cardinality
PRIMARY		Yes		umeta_id		4794868	
user_id_2	Yes		user_id			197093	
				meta_key		5135703	
user_id		No		user_id			206846	
meta_key	No		meta_key(191)		6400

a unique (user_id, meta_key), an index on (user_id) and (meta_key)

• This reply was modified 3 years, 9 months ago by Corey.

@champsupertramp Just checked and that option is not checked, so it shouldn’t be disabled.

This was an import and merge from both a Drupal website and previous WordPress site. Maybe I need to warm the cache, is there any way to force it to cache each user?

@champsupertramp confirming that Ultimate Member is running equally as slow without any other plugins installed.

There are 5 million user metafields in that table that the query needs to sort through.

Any thoughts? Can that query be disabled and/or is there any reason it would be running on every single page?

• This reply was modified 3 years, 9 months ago by Corey.

@champsupertramp I’ll give that a try in the morning! I have copied that query and run it directly in phpmyadmin though, and it still takes 8-9s to complete — so I don’t believe disabling other plugins will solve this.

I’ll give it a try though!

I was able to install the plugin: Query Monitor which gave me some info on what query was causing the delay. It appears the query below is running on every single admin page and is now taking 9 seconds to complete. There are 5 million usermeta rows in the database currently. This query only seems to run on the admin side:

SELECT DISTINCT SQL_CALC_FOUND_ROWS wp_users.ID
FROM wp_users
INNER JOIN wp_usermeta
ON ( wp_users.ID = wp_usermeta.user_id )
WHERE 1=1
AND ( ( wp_usermeta.meta_key = 'account_status'
AND wp_usermeta.meta_value = 'awaiting_email_confirmation' )
OR ( wp_usermeta.meta_key = 'account_status'
AND wp_usermeta.meta_value = 'awaiting_admin_review' ) )
ORDER BY user_login ASC
LIMIT 0, 1

Is there a reason this runs on every page and/or is it something that can be disabled or improved?

• This reply was modified 3 years, 9 months ago by Corey.

The dedicated server it is on has 8 CPU & 16GB of Ram on a SSD

The network / console tab doesn’t say much other than the page takes 17s with PHP before loading the page

I am wondering if this is a memory leak or a bad query somewhere — possibly due to an import.

Does anything come to mind that might cause a slow down / long query loop in UM if something is set up improperly?

Thanks!

• This reply was modified 3 years, 9 months ago by Corey.

This happens to me as well.

Go to: plugins/wp-hashcash/wp-hashcash.php
Comment out: Line 533

`echo ‘<div><input type=”hidden” id=”wphc_value” name=”wphc_value” value=””/></div>’;
//echo ‘<p>’ . __(‘Powered by’, ‘wp-hashcash’) . ‘ WP Hashcash</p>’;
echo ‘<noscript><div><small>Wordpress Hashcash needs javascript to work, but your browser has javascript disabled. Your comment will be ‘.$verb.’!</small></div></noscript>’;`