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

WordPress Trac wp-trac at lists.automattic.com
Fri Jun 29 14:11:58 UTC 2012


#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 redsweater):

 Replying to [comment:6 koke]:

 While I agree that WP shouldn't use inordinately more memory just because
 a larger number of assets was requested, to some extent it is inevitable.
 You should WordPress should use the same amount of memory to return 10 or
 1000 comments, but the 1000 comments will on average take 10 times as much
 memory just for their storage in PHP memory. The problem is worse with
 posts where the amount of data per post is usually much more on average
 than for a comment. When you ask for 300 posts, it often adds up to an
 awfully big single XML response that PHP has to load into memory before it
 sends down the pipe. (I assume - PHP experts disagree?)

 So once any obviously foolish memory usage issues in WP are ruled out, I
 think paging techniques are the way to tackle this. It looks like paging
 was added to wp.getRecentPosts, so you can, instead of asking for 100
 recent posts, ask for e.g. 10 at a time with an increasing offset. It
 means 10 requests instead of one, which means more latency and probably an
 ultimately slower transaction, but at least it's extremely likely not to
 exceed the memory limitations of the server.

 > And what should a client do with memory_limit? How do I translate 32M to
 X comments or categories? I'm willing to reduce the number of items
 requested, but how do we pick that number? We didn't raise the number of
 comments requested and we hadn't heard of memory problems before 3.4

 Just a little feedback as the developer of a blogging client: there have
 been memory issues with WordPress installations for years. It's true that
 it tends to become noticeable around major releases, especially when new
 features or the default theme in WordPress push PHP memory usage up just
 enough to be "near the edge" for whatever the user's hosting configuration
 is. Users typically have to solve the problem either by asking their
 server administrators to raise the PHP memory allocation for their
 account, or by manually editing it if empowered to do so in a .htaccess
 file.

 > I find interesting that a mobile phone can handle a data size that a
 server can't. IMO, it's a XML-RPC problem. The way we deal with big XML-
 RPC requests is by using file streaming:
 https://github.com/eczarny/xmlrpc/issues/11

 Hmm - that's pretty cool. I guess that might be the "PHP experts" answer
 to my assertion above that PHP has to load everything into memory. I would
 very much welcome any changes in WordPress that would make it less
 vulnerable to the out of memory issues that are liable to occur with large
 requests.

 Daniel

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


More information about the wp-trac mailing list