[wp-trac] [WordPress Trac] #34560: High memory usage ( and possible server error) editing post with many/large revisions

[WordPress Trac]

#34560: High memory usage ( and possible server error) editing post with many/large
revisions
-------------------------------------+-------------------------------------
 Reporter:  pdfernhout               |       Owner:  adamsilverstein
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Future Release
Component:  Revisions                |     Version:  3.6
 Severity:  major                    |  Resolution:
 Keywords:  needs-unit-tests has-    |     Focuses:  administration,
  patch dev-feedback needs-testing   |  performance
-------------------------------------+-------------------------------------

Comment (by mikeyarce):

 @adamsilverstein I agree with your points!

 **tl;dr:**  I've got a patch that addresses the performance of
 `wp_get_post_autosave` and `wp_get_post_revisions` and fixes a case where
 Gutenberg has a fatal error when loading posts with many revisions.  There
 are still some issues with Classic Editor but those are beyond the scope
 of this patch.

 Patch:
 https://core.trac.wordpress.org/attachment/ticket/34560/34560.15.diff

 == Autosaves

 I tried several approachess with how to get the `autosave`, and I found
 that using a custom query was the best solution.
 `wp_get_post_autosave` now uses a custom query just to get the autosaves,
 pretty much the same as the diffs above.

 == Revisions

 With `revisions`, I looked at the performance of getting a count of
 revisions vs a query for just the `ids`, and I found that while a query
 for just a count was faster, the context where we need a count would also
 require extra queries which would negate the benefit.  For example, in
 `class-wp-rest-posts-controller.php`, we need both a count of revisions
 and the ID of the last revision.

 `wp-admin/includes/meta-boxes.php` now just queries the revision IDs
 instead of retrieving entire revisions.
 `class-wp-rest-posts-controller.php` already just gets revision IDs, we're
 all good there.

 == Things I tried that did not work

 I tried adding a new function just to get the revision count, but in the
 contexts we see, it meant additional calls were often needed, like to get
 revision IDs, which made less of a performance improvement.

 I tried using WP_Query to get the `autosave`, but not currently possible
 to use WP_Query for a specific `post_name`.

 == Unit Tests
 Unit Tests had to be updated because the `wp_get_post_autosave` now
 returns `stdClass` instead of `WP_Post` object.

 Unit Tests patch:
 https://core.trac.wordpress.org/attachment/ticket/34560/34560.14-tests.diff

 == Performance
 I ran a lot of test scenarios to see what kind of performance gains we
 have with this patch.
 Method:  I used 2 test posts, a Small Post (20kb) and a Large Post (2MB),
 with differing amounts of revisions and autosaves, and profiled the size
 of the request and the timing.

 Here's what I found:

 [[Image(https://core.trac.wordpress.org/raw-attachment/ticket/34560/small-
 post-performance.png)]]
 [[Image(https://core.trac.wordpress.org/raw-attachment/ticket/34560/large-
 post-performance.png)]]

 The improvements are really noticable in posts that have lots of revisions
 (100+), but all around I could see performance improvements on both the
 Classic Editor and Gutenberg.

 The Classic Editor still has some issues once you get into a high number
 of revisions because it lists them all out in a meta box with
 `wp_list_post_revisions`.  To tackle that specific issue, we should
 probably open a new bug to look at adding pagination to that meta box.

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