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

 This is a very active ticket and I recognize that a lot is going on and
 there are several different important discussions mushed together, and
 that everyone else here has spent more time on the problems than I have,
 and so please take this with that awareness that I’m not going to be as
 knowledgeable as others.

 As I read through this to try and get up to speed, I think one salient
 point was lost: the role of update frequency. When this conversation
 started it seemed to contrast the //infrequent// updates from the existing
 heartbeat with the //frequent// updates from collaboration.

 1. If these sync and awareness/presence updates occurred less frequently,
 on par with the heartbeat, would this be the problem it is?

 And that paired with another question I had, which was something that
 seemed surprising to me.

 2. Why are there so many updates occurring when the post isn’t changing?

 On this second point I must be misunderstanding because I can’t imagine
 why we would have four updates per second when the editor is sitting open
 and idle. We are grabbing changes from the post and I would expect that we
 cull //any and all// updates which present no changes.

 And presence or awareness isn’t something I’ve seen people want a history
 for, so //at a minimum// it seems more suited for transients than database
 storage. //Especially// if clients are reporting in as frequently as it
 seems like they are, then a complete loss of this information should be
 restored instantly, for all practical definitions of “instant.”

 ----

 Given the timeline and still-broad discussion of scope, design, and even
 table counts or names, can this be resolved inside a temporary structure
 now and gracefully updated to a table once we have more time to iron out
 the basics?

 ----

 Answering here for completeness and because it was brought up, but I don’t
 see these comments being super related here, and I wouldn’t want them to
 delay or distract from the issues at hand.

 > explored synchronizing the databases…knowing when something in the
 database changes…

 The work we have done concerning a `wp_sync_state` table are designed to
 add a kind of versioning to all WordPress objects, efficiently track
 updates across an entire site, and self-heal in the presence of changes
 which are outside of WordPress purview. It’s more concerned about knowing
 //whether// a resource has (probably or definitely) changed since a given
 moment in time rather than assessing what those changes are exactly.

 It dovetails well into this work, though it’s not likely directly
 applicable to shared transient editor state. The tie-in we did work on,
 however, was building a single-writer worker in WordPress to handle all of
 the inbound changes. That would leave one PHP process per document being
 concurrently edited and could hold this awareness/presence information
 without tables or transients — just PHP variables. That work does depend
 on having another new table though, an inbound work queue.

 > an improved search feature that distinguished rendered text from HTML
 syntax. That search index might make a better fit for the synchronization
 work as it uses a similar schema and tries to answer a similar question:
 "did this row change after it was indexed?"

 The generalized change-tracking system has a lot of potentially utility
 because every operation (search indexing, database upgrades, cache
 regeneration, WordPress syncing) is just another “sync client.” It breaks
 down for the transitional states which appear while edit sessions are in
 progress; performing their job once a post revision is actually created.

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