[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
--------------------------------------+--------------------------

Comment (by JoeFusco):

 I could be wrong, but `add_post_meta()` unconditionally calls
 `wp_cache_delete( $object_id, 'post_meta' )` inside `add_metadata()`
 ([https://github.com/WordPress/wordpress-
 develop/blob/5f2be9e5a5bb4bed05fd997df8de11335b442c65/src/wp-
 includes/meta.php#L145 meta.php:145]). `update_post_meta()` does the same.

 Since sync updates and awareness state share the same storage post per
 room, every sync write and every awareness write (1-4x/sec per editor)
 invalidates the entire meta cache for that post - including all other
 cached meta keys. The next `get_post_meta()` call for awareness misses
 cache and hits the database, even when awareness data hasn't changed. I
 don't believe this has been addressed yet.

 After r62064, 2 of 5 operations already bypass the Meta API with raw SQL.
 Fixing this would require bypassing `add_post_meta()` and
 `update_post_meta()` as well - bringing it to 4 of 5.  At that point the
 remaining `get_post_meta()` would be reading from a cache that nothing is
 priming, so it would also need to be replaced. That's 5 of 5 operations on
 raw SQL against `wp_postmeta`.

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