[wp-trac] [WordPress Trac] #34560: Server error after saving many revisions

[WordPress Trac]

#34560: Server error after saving many revisions
-------------------------------------------------+-------------------------
 Reporter:  pdfernhout                           |       Owner:
     Type:  defect (bug)                         |  adamsilverstein
 Priority:  normal                               |      Status:  assigned
Component:  Editor                               |   Milestone:  Future
 Severity:  major                                |  Release
 Keywords:  needs-unit-tests has-patch dev-      |     Version:  3.6
  feedback needs-testing                         |  Resolution:
                                                 |     Focuses:
-------------------------------------------------+-------------------------

Comment (by pdfernhout):

 Replying to [comment:11 adamsilverstein]:

 @adamsilverstein Thanks! Since you went to all the trouble to make this
 patch, and so quickly, after looking at the code, I thought the least I
 could do was test it in production. :-)

 So, I put the website with the issue under git source control (just in
 case, and a good thing to do anyway) and fired away with "patch <
 34560.3.diff" (on top of 4.3.1). The site seems to still be running OK
 (crossing fingers).

 Here are some memory statistics after patching as reported by WP-Memory-
 Usage:

 {{{
 Viewing plugin admin panel: 23.69 of 256

 Editing simple page about 1K with 17 revisions: 27.21 of 256

 Editing 437K page with 338 revisions Memory : 91.81 of 256

 Looking at a revision of the big page: Memory : 88.83 of 256
 }}}

 It's a huge improvement in that I can edit the page again (in theory, as I
 have not actually tried saving a new revision yet). Also, instead of the
 page consuming more than 256MB (causing the server error), there is about
 160MB still free. Big score! Thanks!

 However, looking at the numbers, there is obviously something I still
 don't understand here. It seems to me that the big page of 437K should
 still only take less than a megabyte more to edit than the tiny one. I can
 guess that all the extra memory must be in having the revisions list for
 the page, both when editing a page and when looking at the revisions list?
 Or could there be another reason (character representation issues or
 whatever)?

 If it is the revisions using up all the memory, are all the retrieved
 items needed in the new function "wp_get_post_revisions_details"? Those
 are: "ID, post_author, post_date, post_date_gmt, post_title, post_status,
 post_parent, post_modified". I see the convenience of having them all, but
 are some invariant (like ID) or unneeded (like title)? Or could the list
 be passed into the function perhaps if only some users need them? The
 revision list in the editor only displays author and timestamp information
 (and a relative time derived from the timestamp). It does not display this
 other information (size of the content might be nice in the revision list
 though, if that was doable, but a different issue). If the fields are all
 needed, as a more substantial future change (which could be its own new
 issue), perhaps the revisions list in the editor could drop down and only
 retrieve the revision metadata then? Most of the time I'm editing
 something the revisions list is not needed in the editor and just adds
 clutter. But I'm still not thinking those extra fields of revision
 metadata are the issue, even if these sorts of changes might make very
 minor improvements in memory use (and maybe not worth the effort). ID is
 an int, so 338 of them is not going to take up that much space, and even
 title strings are unlikely to be more than 100 bytes each, so 34K more
 total, and so on.

 Something still does not add up to me if 338 revisions are using about
 63MB. That is about 186K per revision, which seems way too much for a few
 strings. In fact, that is suspiciously again like maybe the average amount
 of memory needed for the big page per revision, as it is about half the
 final size, given the page grew slowly over time. I'm wondering if maybe
 somehow WordPress has been retrieving more than one copy of all the post
 revisions all this time and maybe the patch you made (similar to my
 original suggestion, but better) only gets rid of most of those sets of
 revisions -- but one other last set of unneeded revisions is lurking in
 WordPress somewhere?

 Or maybe there is just some other reason to explain this? How much memory
 should a revision's metadata typically take? I just don't expect it taking
 much more than 1K or so per revision even with all the fields the latest
 patch retrieves, or about 338K max in this case. Or am I just way off base
 here or missed a couple decimal points somewhere or something?

 BTW, for the memory use figures you provided, it would be useful to have a
 baseline memory value in the "after" case for a small page with just a few
 revisions to compare, similar to the comparison I did above, to see if
 this is maybe just something weird about my particular system (maybe from
 plugins or something). Then we can compare the difference from the
 baseline with the expected memory use of all the revisions generated by
 the version of the script you used to generate them and see if they match
 up.

 I've never used XDebug myself, but maybe that tool or a similar one might
 provide some insight here?

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