[wp-trac] [WordPress Trac] #64696: Real time collboration effectively disables persistent post caches while anyone edits a post

[WordPress Trac]

#64696: Real time collboration effectively disables persistent post caches while
anyone edits a post
--------------------------------------+--------------------------
 Reporter:  peterwilsoncc             |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Posts, Post Types         |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------
Description changed by peterwilsoncc:

Old description:

> When real time collaboration is enabled, any time the post editor is open
> the persistent caching for `WP_Query` is effectively turned off due to
> the frequent updates to the `wp_sync_awareness` meta key.
>
> Any time post data is updated, the post's `last_changed` time up updated
> in persistent caches to indicate the entire `WP_Query` (and various other
> post caches) need to be invalidated.
>
> To reproduce:
>
> 1. Configure a site with a prescient cache
> 2. Enable real time collaboration
> 3. Without an editor open, run the WP CLI command `wp eval "var_dump(
> wp_cache_get_last_changed( 'posts' ) );"` a couple of times, a few
> seconds apart
> 4. Observe that the value does not change between calls.
> 5. Edit a post, any post type will work.
> 6. run the WP CLI command `wp eval "var_dump( wp_cache_get_last_changed(
> 'posts' ) );"` a couple of times, a second apart
> 7. Observe that the value does changes every second
>
> As objects cached in the `post-queries` group use the outcome of
> `wp_cache_get_last_changed( 'posts' )` to salt their caches, this means
> that leaving the editor open will effectively prevent the caching of post
> queries throughout the site.
>
> Reducing the frequency the `wp_sync_awareness` meta data is updated will
> reduce the severity of the problem, if that's possible.
>
> To an extent this is an inevitable effect whenever the RTC syncing data
> is stored in the post and post meta tables, ideally it would be limited
> to only occur when an edit is made so that leaving a browser tab open
> doesn't have negative implications on the performance of a site.
>
> I've put this on the 7.0 milestone for the purposes of investigating the
> issue to see if mitigation is option.

New description:

 When real time collaboration is enabled, any time the post editor is open
 the persistent caching for `WP_Query` is effectively turned off due to the
 frequent updates to the `wp_sync_awareness` meta key.

 Any time post data is updated, the post's `last_changed` time up updated
 in persistent caches to indicate the entire `WP_Query` (and various other
 post caches) need to be invalidated.

 To reproduce:

 1. Configure a site with a persistent cache
 2. Enable real time collaboration
 3. Without an editor open, run the WP CLI command `wp eval "var_dump(
 wp_cache_get_last_changed( 'posts' ) );"` a couple of times, a few seconds
 apart
 4. Observe that the value does not change between calls.
 5. Edit a post, any post type will work.
 6. run the WP CLI command `wp eval "var_dump( wp_cache_get_last_changed(
 'posts' ) );"` a couple of times, a second apart
 7. Observe that the value does changes every second

 As objects cached in the `post-queries` group use the outcome of
 `wp_cache_get_last_changed( 'posts' )` to salt their caches, this means
 that leaving the editor open will effectively prevent the caching of post
 queries throughout the site.

 Reducing the frequency the `wp_sync_awareness` meta data is updated will
 reduce the severity of the problem, if that's possible.

 To an extent this is an inevitable effect whenever the RTC syncing data is
 stored in the post and post meta tables, ideally it would be limited to
 only occur when an edit is made so that leaving a browser tab open doesn't
 have negative implications on the performance of a site.

 I've put this on the 7.0 milestone for the purposes of investigating the
 issue to see if mitigation is option.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64696#comment:74>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform