That seems likely on a very large multisite. Authorizer stores its lists (approved, multisite approved, pending, blocked) in wp_x_options as a serialized array, so it will scale upwards the more users you have.
Can you try setting autoload='no' on the various auth_* options in the database and see if that reduces the memory footprint? If so, we can disable autoloading, but bear in mind that those options will still need to be loaded on demand (e.g., when viewing Authorizer Settings in wp-admin, or when a user logs in).
Thanks for the response!
This multisite only has about 85 users total, with most on the base site, and the high RAM use is specifically when loading the Authorizer options page, not elsewhere. In fact, the site owner discovered they could approve/deny new users from the widget Authorizer adds to the main Dashboard page, because that doesn’t seem to consume any more RAM than usual. It’s just the Authorizer settings page that wants well over the 128 MB we normally allow PHP sessions.
Since the base site has the biggest issue, I tried setting all of its auth_* options to not autoload, but that didn’t have any impact on the memory used.
One additional thing that’s worth mentioning is they’re using User Role Editor Pro to define custom user roles. They have other memory use issues too (they have 27 plugins active and most settings pages take between 30 and 97 MB to render), but the Authorizer dashboard pages definitely use the most RAM by far.
Oh interesting, thanks for the details and excluding the authorizer options as the cause.
Have you used the Query Monitor plugin before? I just used it to do a quick profile of the Authorizer Settings page on a test multisite install, and it reported 8.0 MB peak memory usage. It will appear in the admin bar for Administrator users, and you can also see memory usage in the Overview tab if you open the Query Monitor panel (which mimics the browser’s Developer Tools). If you’re willing, also review the Database Queries tab and sort by number of Rows, perhaps there is a query that returns a large dataset on your specific install.
https://wordpress.org/plugins/query-monitor/
They actually already were using Query Monitor, so I bumped up the PHP memory limit enough so the Authorizer settings page would load in non-Production and took a look.
Yowza! A series of calls from WordPress Core running update_meta_cache() against blocks of specific post IDs. Each query returns between a few thousand and almost 50,000 rows. Any idea what it’s doing there or why it would be doing that on the Authorizer settings page? It’s not doing it on the regular Users page.
Hm. There are two Authorizer settings that could be related, one to show a list of pages (so you can select which ones are public if you set your site to private mode), and another to choose a user meta value to show in the Approved User list for each user. It sounds like the meta cache is related to posts, so I’m inclined to think the first.
Can you try commenting out the lines below and see if that eliminates the calls to update_meta_cache()? https://github.com/uhm-coe/authorizer/blob/master/src/authorizer/options/class-public-access.php#L176-L181
If so, we can pass update_post_meta_cache => false as a param to get_posts() which should fix it. Thanks!
That seems to have made a remarkable difference. 181 MB -> 28 MB to render the options page (plus an error about $pages not being defined, of course) with that section commented out. With 'update_post_meta_cache' => false, added to the array of flags to get_posts(), the memory use of the options page on this site goes back up a little to 58 MB, but that still seems reasonable.
Thanks!
Awesome. Version 3.8.3 is now out with this fix.
We also disabled a few of the other cache options so hopefully it will drop a little lower than the 58 MB. https://github.com/uhm-coe/authorizer/commit/1c33ff844cbacd6f8fda143ff543e3ffa3003f7a
Thanks for your help!
