slow queries

Thanks for the kind words and for your report. Thanks as well for taking the time to run some experiments with the excellent Query Monitor plugin.

You don’t specify which screen you are measuring but I assume you are working with the Media/Assistant admin submenu; is that right?

Looking at your results the obvious cause of the problem is MLAReferences::mla_attachment_array_fetch_references_handler(). The other queries are small fractions of a second. The offending function is used to create the “Where-used Reporting” results. It looks for all of the custom image sizes because any of them could be inserted in a page/post. There is an option setting, “Base”, that simplifies the query and omits the intermediate size specifics.

It’s great information when you need it, but mostly you don’t and it is expensive to compute. You can turn these features off entirely by going to the Settings/Media Library Assistant General tab, scrolling down to the “Where-used Reporting” section and setting all four “Where-used database access tuning” options to “Disabled”. Don’t forget to scroll to the bottom and click “Save Changes” to record the new settings.

I changed the default setting for these features to Disabled some time back but your settings may be different. If all four of the options are already set to Disabled and you still see the offending query, let me know where that’s happening and I will investigate further. I’ll also look at the other queries you mentioned. Let me know what you find, and thanks for your interest in the plugin.

I looked into the other queries you mentioned:

• wp_count_attachments() – This is a WordPress function that computes the “items per view” numbers shown in parentheses after each view, e.g., “All”, “Images”. I don’t see a faster way to calculate these numbers.
• WP_Term_Query->get_terms() – This is called from several different places for different reasons. More details below.
• WP_User_Query->query() – This is called from within a WordPress function that creates a dropdown list of authors. This function is called twice to format the list in two different ways. WordPress does not cache the results from one call to the next, probably because it’s not worth it. –

Regarding WP_Term_Query->get_terms() I was able to make a few improvements but I doubt they affect your experience. This function is called in several places:

• Called once to cache the terms assigned to items shown on the current Media/Assistant page.
• Called for each “table view” added in the Settings/Media Library Assistant Views tab. I was able to eliminate these calls.
• Called twice for each taxonomy displayed in the Bulk Edit and Quick Edit areas. I was able to eliminate one of the two calls.
• Called, as you observed, from dropdown_categories() and terms_checklist(). These are WordPress functions that format the results in completely different ways. I have no control over their database access and caching behavior, but I am reluctant to replace them with my own code. I try to use WordPress functions wherever possible for maximum compatibility.

I am always looking for ways to improve performance and I appreciate the opportunity to look into the calls you identified. I look forward to any other feedback and details you can provide. Thanks for inspiring some MLA improvements.

@dglingren

Now that is what I call a response that helps me climb the hill, thank you for your detailed answer and immediate action. Awesome!

I was indeed working with the Media/Assistant menu item.

About the settings you mention:

While using the Query Monitor, the settings were the following:

• Featured in Enabled
• Inserted in Base
• Gallery in Disabled
• MLA Gallery in Disabled

After reading your comment on “Base” it seems to me that the settings are not being honored properly, because they have been like this from the moment I started using the plugin and that’s years ago… Confused.

I understand you prefer using WordPress functions instead of your own code. Compatibility is a key ingredient and apart from the MLARef query we are talking about fractions of a second that do no harm.

“Featured in” I’ve kept enabled and the others are set to Disabled.

Later today I’ll do three things:

• Measure the same screen with the Query Monitor.
• Switch on debug for a while.
• See what gives and let you know.

I’ve never seen any errors from this plugin during previous debug sessions, but I’ll set the mla_debug_level to 3, just in case.

Cheers and thank you so far, glad to have inspired you a bit!

Thanks for your update and for the positive feedback; much appreciated.

Regarding the default settings, the change to “disabled” was with v2.20 released on 06 December 2015. If your MLA install goes back farther than that the settings you report make sense.

Leaving “Featured” enabled will populate the “Featured in” column on the Media/Assistant admin screen and on the Media/Edit Media screen for a particular item. It requires one fairly efficient query and shouldn’t affect performance very much.

I am marking this topic resolved, but please update it if you find anything else I should have a look at. Thanks for your help with this aspect of MLA.

Hi David,

I’ve done some debug runs, changed some settings and here are a two more of my cents ??

MLAReferences::mla_attachment_array_fetch_references_handler() 0.0036 (Featured in enabled)
MLAReferences::mla_attachment_array_fetch_references_handler() 2.1635 (Featured in enabled, Inserted in Base)

As you say, no big deal in terms of query-time.

Some oddities while debugging that I can live with, but they make me raise my eyebrows a bit:
Settings according to options-general.php?page=mla-settings-menu-debug&mla_tab=debug:

MLA_DEBUG_LEVEL 0x0001
WP_DEBUG false
WP_DEBUG_LOG false
WP_DEBUG_DISPLAY true

First and only line in MLA_Debug file:

[28-Nov-2017 18:53:12] 582 MLACore::mla_plugins_loaded_action() MLA 2.64 () mla_debug_level 0x3

Settings in wp-config.php:
/** WordPress DEBUG */
define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);

Feedback well deserved, David. I wish your way of dealing with a support request were default amongst (plugin) developers.

As far as my debug results and oddities: don’t let them keep you awake at night, just a matter of curiosity on my end and maybe it’s a good idea to do a fresh install of the plugin to get rid of some artefacts in the database.

Thank you!

Thanks for your comments and additional details. Thanks as well for your positive review, which is a great motivator to keep working on the plugin and supporting its users.

I am not sure what raised your eyebrows, but here are some clarifications. Again, history and evolution play a significant role:

1. The MLA_DEBUG_LEVEL constant was the original way to activate the Debug tab, usually added to the wp-config.php file.
2. Later I added the “PHP Reporting” and “MLA Reporting” values to make it easy to adjust reporting without editing files. Essentially, “MLA Reporting” overrides MLA_DEBUG_LEVEL.
3. In the latest MLA version I changed the default MLA_DEBUG_LEVEL from zero to one. That means the Debug tab appears by default but can be suppressed by defining MLA_DEBUG_LEVEL 0 in wp-config.php.

You entered MLA Reporting as “0x3”. That activates two of the many categories documented in the “MLA Debug Tab” section of the Documentation; “any” and “AJAX”.

Generally, the “any” category includes the single message you observed and messages reflecting warnings and errors in the MLA application. You won’t see anything else unless something goes wrong. The AJAX category will generate a LOT of messages for specific actions such as Bulk Edit and IPTC/EXIF mapping. The other categories let me turn on messages for specific support problems.

For normal operation you should use MLA Reporting “0”. The WordPress settings (WP_DEBUG, etc.) only generate messages when something goes wrong.

When you made changes to your MLA General settings and saved them MLA cleaned out the older artifacts from the database. You shouldn’t have to do a re-install to clean anything up. You can always “Export all settings” to a file, “Delete General Options and restore default settings” to see the current defaults and then “Import all settings” to get back to where you were.

Hope that helps. Let me know if you have other problems, questions or comments. Thanks again!

Thank you once again, David!

With the history/evolution droplets I now understand what I saw.

Cheers!