Make WordPress Core

Opened 13 years ago

Last modified 3 weeks ago

#17382 new defect (bug)

XMLRPC wp_getUsersBlogs Scalability

Reported by: bmorneau's profile bmorneau Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.0
Component: XML-RPC Keywords: needs-patch needs-testing
Focuses: Cc:

Description

If there is a root blog with many sub blogs on it and a user that is an admin on each sub blog, then when the when the XML RPC method wp_getUsersBlogs() is called it does not scale very well. My PHP memory_limit setting was 128MB, and the XML RPC request died when a user was a member of 230+ blogs. I noticed that the number of queries made to the database for a single user that has many blogs that they are an admin is very high.

Affected line: http://core.trac.wordpress.org/browser/tags/3.0.1/xmlrpc.php#L443

I don't know exactly how the code would have to change so I am not providing a patch.

Change History (6)

#1 follow-up: @josephscott
13 years ago

  • Cc josephscott added

I think this is a bit of an edge case, I don't expect to see too many people with more than 200 user accounts on a single WP install. The only short term fix is to increase your allowed memory setting to deal with processing that much data.

Long term, we'd probably need some sort of paging ability so that you can request the list in chunks.

#2 in reply to: ↑ 1 ; follow-up: @ericmann
13 years ago

Replying to josephscott:

Long term, we'd probably need some sort of paging ability so that you can request the list in chunks.

+1 for paging the response. We would probably want to set it to return only the first 50 blogs or so by default for performance, but you could override that with any number or just make multiple requests for multiple pages of results.

#3 in reply to: ↑ 2 @bmorneau
13 years ago

Replying to ericmann:

Replying to josephscott:

Long term, we'd probably need some sort of paging ability so that you can request the list in chunks.

+1 for paging the response. We would probably want to set it to return only the first 50 blogs or so by default for performance, but you could override that with any number or just make multiple requests for multiple pages of results.

With the platform I work on there are approximately 350+ blogs on a single network and a few users who are Super Admins in addition to having admin roles on each blog. We have other networks as well that have an increasing number of blogs and users with Super Admin/Admin privileges. Paging would definitely be a more optimal solution to this.

#4 @mohanjith
12 years ago

Patch for #20665 should fix the out of memory issue

+1 for pagination in the long run

#5 @chriscct7
9 years ago

  • Version changed from 3.0.1 to 3.0

#6 @desrosj
3 weeks ago

  • Keywords needs-testing added
  • Milestone set to Awaiting Review

I came across this scrubbing the list of tickets missing a milestone.

It looks like #21432 attempted to deprecate some multisite functions in favor of switch_to_blog() because it had become more performant (this included current_user_can_for_blog(), which was the approach taken in [21194] for #20665). Though that ticket is still open and unsolved as well.

There have been a lot of multisite focused improvements focused on performance over the last 12 years, but there is likely still a tipping point where this problem surfaces. Is anyone still experiencing this today or able to easily do some performance testing to gauge how big of an issue this is today in 6.6?

Note: See TracTickets for help on using tickets.