[wp-trac] [WordPress Trac] #62057: Addressing Autosave Memory Issues

[WordPress Trac]

#62057: Addressing Autosave Memory Issues
--------------------------+------------------------------
 Reporter:  whyisjake     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Autosave      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  rest-api
--------------------------+------------------------------

Comment (by tallulahhh):

 Here's some context around risk of **Autosave Parallelism**...

 When loading a post, the WP editor preloads data from a bunch of rest
 routes in the `preload_paths` array in `wp-admin/edit-form-blocks.php`,
 including one for the post's autosaves, that looks like this:
 `wp-json/wp/vw/posts/123/autosaves`

 Since the full autosaves route payload includes the_content of ''each
 autosave'', and retains 1 autosave per user that's ever edited the post,
 this can become large quite quickly!

 In a situation where a post has an extremely large number of autosaves or
 very large autosave content, this can create a PHP OOM when the
 (potentially massive, unchecked) payload from the autosaves route is
 loaded by PHP, making the post OOM and seem impossible to load/edit in the
 editor.

 This has been observed in the wild, with OOMs, in sites with a variety of
 users editing longstanding posts with long content.

 It can be verified by measuring PHP memory usage in the editor - posts
 with a large autosave preload payload will consume more PHP memory. With
 some multiple megabyte pastes of lorem ipsum in the editor, and 1min to
 allow the autosave/s to take place, the difference is noticeable.

 The PHP OOM risk can be mitigated by simply not preloading them, by
 removing the autosaves route from `preload_paths` - which instead makes JS
 load it directly from the rest route. Previously-affected large posts with
 large/many autosaves don't PHP OOM once the preload is prevented.

 Specifically, this PHP OOM risk can be avoided by removing this line from
 `wp-admin/edit-form-blocks.php`:
 `sprintf( '%s/autosaves?context=edit', $rest_path ),`

 This method (or doing it in a filter to
 `block_editor_rest_api_preload_paths`) is reliable for sites that skirt
 the upper limits of autosave parallelism.

 Steps to verify:
 - Make a post with at least one autosave
 - load it in the WP editor with browser devtools looking for requests with
 'autosave'
 - with the autosaves preload, PHP loads it and no rest route request is
 made
 - without the autosaves preload, JS load it and the network request for it
 visibly fires on editor load
 - PHP memory profiling can further verify that the preload doesn't hit PHP

 It still raises the issue though that Gutenberg's JS is loading the full
 payload of all autosaves for every post the editor loads, which can be
 suboptimal at scale...

 In theory, the editor technically only needs the ''dates'' of existing
 autosaves to see if a newer one exists when opening a post - which could
 be done using a fields arg for the initial request - at which point it
 could then (if needed) load an individual autosave from the rest route by
 ID to diff against the editor content. This could keep autosave-based
 memory consumption/waste down in the editor in general.

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