[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 peterwilsoncc):

 Following in person and slack discussions, I think there is broad
 agreement to go with the approach in [https://github.com/WordPress
 /wordpress-develop/pull/11348 PR#11348] for the 7.0 release:

 Meta/Query API changes:

 * Just-in-time cache invalidation introduced to the post meta API
 * This introduces the option `jit_cache_invalidation` to `register_meta()`
 and wrapping functions
 * No changes to what can be queried in `WP_Query`
 * No changes to `WP_Meta_Query`
 * `WP_Query` will self flush it's cache on the next meta query following
 the modification of JIT invalidated meta data
 * @ellatrix I've taken this approach as it maintains back compat for third
 parties; reduces the need for `NOT` db queries; and bypasses a number edge
 cases it avoids around post types (`all/any` keywords, multiple post type
 queries) and avoids having to decide if meta queries should be dropped,
 replaced with `WHERE 1 = 0`

 JIT cache invalidation applied to:

 * `_edit_lock` (heartbeat API, all post types)
 * `wp_sync_update_data` (RTC, `wp_sync_storage` post type)

 Sync storage updates:

 * Awareness: stored in transients to avoid thrashing post meta & WP_Query
 cache. As time limited transients, the `alloptions` cache is unaffected.
 * Awareness: granularity is reduced to 10 seconds, rounded up, to avoid
 updating the option/cache entry every time a HTTP request is made.
 Awareness lasts between 30 and 39 seconds as a result which no one using
 RTC will ever notice
 * Awareness: the transient is stored for a day to allow re-use when people
 return to a room on the basis that the more recently a room is used the
 more likely it is to be reused again soon.
 * Updates: adding an update uses the `add_meta_data` API
 * Updates: deleting updates for compaction still uses a direct DB query
 but triggers the need for JIT cache invalidation

 I'd prefer to use the `get_post_meta()` and `delete_post_meta()` APIs
 rather than direct DB queries, I've asked Chris to help out with a tl;dr
 on the issue so I can consider potential solutions.

 I've followed up the source code changes/questions by @jorbin, @czarate,
 @zieladam and @desrosj. I've redirected a question about the test suite to
 Chris. In addition to the reviewers, I've run the PR pas @griffbrad for a
 logic check.

 I don't know that anyone will be 100% satisfied with using post meta but I
 think we have a solution that most people will be mostly happy with that
 avoids the cache thrashing in the description of this ticket.

 The steps for verifying the fix in [comment:111 comment #111] still
 largely apply but you need to open the post in TWO tabs and make some
 changes now.

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