andyphillips82

I started checking random posts in our DB. One post, with no oEmbeds, has 87 embeds associated it in the post_meta table.

Any idea what would cause this behaviour?

The only thing I can see that would possibly have this impact is this PR.
https://github.com/xwp/wordpress-develop/pull/225/files

Around oembeds. But I can’t see why.

Actually I think that does help.

We’re seeing the issue around /feed/ and the_content.

oEmbeds update post meta for a cache purpose, so possible that those selects are going to master because of the oEmbeds update_post_meta.

Hoping the spikes are actually more around DB maintenance, as post_meta is the only table we’re having issues with.

thanks!

Did a bit more digging and saw selects going to the master DB before 4.8.2.

Any idea why we’d be getting select queries to our master DB?

Deployed the HyperDB code we found in 1.3 (svn) and it took our site down. Flooded master with requests.

Created a plugin that works in conjunction with debug bar. Sort of hacky, but gets the job done.

https://github.com/andyphillips82/wp-page-transient-flush

You’ve gathered the list of transients used on that page.

Could you not in theory create a button that when clicked, loops through the list of those transients and uses the delete_transient WP function?

Thanks! In your 0.5 notes I see you wrote,

Performance boost! Removes redundant exists call from wp_cache_get(), which easily halves the number of Redis calls.

I’m assuming that should make a positive impact on our situation?

Just wanted to add. We saw this with 0.4. Just upgraded to 0.6 to see if that helps.

My Fix,

Don’t update the option to ”
Pass a paramter from flush_rules to wp_rewrite_rules of true
Set default to false in wp_rewrites rules
Only update rewrite rules if that options is true.

I believe the issue is that parse_request hits wp_rewrite_rules and passes if ( empty($this->rules) ) this conditional and sets the rewrites.

Both good ideas, attempted both with no success. But, I think I figured it out. I think it’s a WP core scalability issue. When you flush the rewrite rules, it deletes the options. In wp_rewrite_rules there is a conditional to stop other actions from updating the rewrites in the wrong context.

However, if I flush rewrites and while it’s processing the rewrites and another request comes in, it passes that conditional before the update_option happens, it will write it’s own rewrites.

Here’s my gist for the solution
https://gist.github.com/andyphillips82/9bd0cdab46dd01638181693343e08c72

Only flush_rewrites should update the rewrite rules, parse request should only get them.