Uncached SQL queries on every page load.

[spacedmonkey]

• [x] I've read and understood the contribution guidelines.
• [x] I've searched for any related issues and avoided creating a duplicate issue.

Please give us a description of what happened.

Using the plugin query monitor, I am seeing raw uncached sql queries run on every page load. See screenshots.

Please describe what you expected to happen and why.

After second page load, these queries should be cached.

How can we reproduce this behavior?

Technical info

• If relevant, which editor is affected (or editors):

• [ ] Classic Editor
• [ ] Gutenberg
• [ ] Classic Editor plugin

• Which browser is affected (or browsers):

• [ ] Chrome
• [ ] Firefox
• [ ] Safari
• [ ] Other

Used versions

• WordPress version: 5.7.1
• Yoast SEO version: 16.1
• Gutenberg plugin version:
• Classic Editor plugin version:
• Relevant plugins in case of a bug:

• Tested with theme:

[Djennez]

@spacedmonkey could you elaborate what's wrong in this situation? It's not new behavior (been there since the indexables release in 14.0).

[spacedmonkey]

@Djennez I just noticed this. I would say these queries should be cached for performance reasons.

The biggest issue, is if multiple queries. On one page request, I was getting 14 queries. On my homepage, I was getting 128 queries. That is a lot.

Enough to take a database server down a peak request times.

[Djennez]

@spacedmonkey can you find why all those posts are individually retrieved from the database on your frontpage? From what I can see, this is behavior that is not present on a default WordPress installation. Also, can you enlighten me on how / what needs to be cached if every one of these queries is retrieving different data, I think I am missing that context?

[Djennez]

Is there any more information available about this issue? As stated before, we can't reproduce the large amount of individual indexable calls on empty WordPress installations, so we expect some sort of conflict. The issue we see here is just the amount of calls, not the fact they aren't cached. Because they're rather fast.

[Djennez]

I'm going to close this due to inactivity without it having sufficient information. If additional information is provided, we'll look into reopening the issue.

[jdevalk]

@Djennez Jonny Harris (@spacedmonkey, the OP of this issue) was asking about it, so I've reopened it for him.

[spacedmonkey]

Thank you for re-opening.

Looking into this issue again, while reviewing new relic logs. I see 3 uncaching MySQL on my pages. See a screenshot from query monitor from my about us page, spacedmonkey.com/about.

These queries are coming from this method. The query seem pretty simple, querying WP SEO's custom table, by object id and type. So the query runs quickly. But simple query like this should be cached. Query by id and type, makes a cache key generation simple.

$cache = wp_cache_get( "$id_$type", 'wp-seo' );

Cache invalidation should be simple, only updating / deleting key when that object is updated. Otherwise, that cache should be valid forever.

I know it is simple query, but for sites under heavily load or under a DDOS attack, 3 queries a page should take the database server and website down. Will to support on this ticket and provide as much information, testing and code review as needed.

[spacedmonkey]

Still awaiting a response on this one.

[carl-alberto]

+1 on this issue