[wp-trac] [WordPress Trac] #21098: Out of memory errors in XML-RPC

[WordPress Trac]

#21098: Out of memory errors in XML-RPC
---------------------------------+------------------------------
 Reporter:  koke                 |       Owner:
     Type:  defect (bug)         |      Status:  new
 Priority:  normal               |   Milestone:  Awaiting Review
Component:  XML-RPC              |     Version:  3.4
 Severity:  major                |  Resolution:
 Keywords:  mobile dev-feedback  |
---------------------------------+------------------------------

Comment (by maxcutler):

 Replying to [comment:8 koke]:

 > It doesn't have to be that way. What I understand WordPress does
 (simplified):
 >
 > * Call wp_get_recent_posts, store the array in memory
 > * Create a new array of posts (in memory) with the right output
 attributes for XML-RPC
 > * Build the XML-RPC response as a string with those posts (again in
 memory)
 > * Output the string
 >

 That's correct.

 > I don't know much about PHP's memory management and when do objects get
 released, but this is using at least 3x the posts size
 >
 > A more memory efficient solution would be:
 >
 > * Output the XML-RPC prefix
 > * Call wp_get_recent_posts, store the array in memory (we probably can't
 get rid of this without redesigning too much)
 > * For each post, output the proper xml representation
 > * Output the XML-RPC suffix
 >
 > There are problems with this too, like not being able to set Content-
 Size in advance, but temporary files could be used to build the xml
 response

 This would be nice to try, except it would require substantially
 refactoring the IXR Server implementation. Since the library appears to be
 abandoned at this point, maybe it's not a big deal to diverge from
 upstream.

 The other downside to a streaming output implementation is that the
 `Content-Length` header is required by the XML-RPC spec. I don't know how
 reliant various client implementations are on that header, but it's a
 potential source of breakage.

 If a server has extremely low memory_limit set, what are the odds that
 writing to temporary files will be successful? Worth considering and
 testing though.

 > Also, this memory problems only happen to a subset of our users, so I
 don't feel it's right to do more requests (more bandwidth/latency) for the
 majority of users. I know WordPress.com can handle that amount of data.
 I'm sure most of the other hosts can too, but I have no idea how to tell
 them apart.

 As redsweater said, as a client author you have to transfer blame to the
 hosting provider. If you set request parameters that work on 90-95% of
 hosts, then you've done due diligence. The remaining 5-10% need to take it
 up with their hosting provider to get it fixed, and you can't waste
 extraordinary effort and code to cater to the outliers.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/21098#comment:9>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software