Site Editor: Loading takes >10s on a distributed database #23662
Labels
[Type] Bug
An existing feature does not function as intended
Comments
ockham
added
[Type] Bug
|
Why would SRTM send a read that follows a write to the master database for the same request? If the write happened locally, it already has fresh data. |
|
IIUC, it might not be the exact same request but a different one, to the same table. |
ockham
added a commit
that referenced
this issue
Jul 6, 2020
Remove some now-obsolete state, and corresponding initial state passed from the server. We've found that the now-obsolete `gutenberg_find_template_post_and_parts()` calls in `lib/edit-site-page.php` were causing a considerable slowdown of the initial page render (see #23662).
|
We think that this issue has been fixed by #22893. I'll report back once we've verified on our HyperDB install. |
|
Yep, looks like #22893 fixed this. |
youknowriad
pushed a commit
that referenced
this issue
Jul 9, 2020
Remove some now-obsolete state, and corresponding initial state passed from the server. We've found that the now-obsolete `gutenberg_find_template_post_and_parts()` calls in `lib/edit-site-page.php` were causing a considerable slowdown of the initial page render (see #23662).
6 tasks
ockham
added a commit
that referenced
this issue
Jul 16, 2020
Add some performance test coverage to the site editor (loading time), specifically to avoid perfomance regressions with regard to template resolution and `wp_template` auto-draft creation (see e.g. #23662). Changes some of the underlying performance test framework to allow for multiple test files.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We've noticed that loading the site editor with a fairly simple one-template theme on a newly created site on a large WordPress installation that uses the HyperDB plugin for replication takes a long time (10-15s).
Our preliminary findings indicate that this is due to queries being sent to the master database (which is in a different data center), as the same doesn't happen in a sandbox that's hosted in the same DC as the master DB.
The reason for queries being sent to master is that SRTM (Send Reads To Master) behavior is triggered, which usually happens when a write operation hits the DB right before a read (or another write) operation. SRTM then sends that subsequent request to master (rather than the replica) in order to avoid reading stale data.
We suspect that this issue is caused by the template resolution algorithm -- specifically by template part auto-draft creation.
cc/ @vindl @Addison-Stavlo @jeyip @noahtallen @epiqueras
Thanks @josephscott for advising
The text was updated successfully, but these errors were encountered: