Make WordPress Core

Opened 13 years ago

Closed 13 years ago

#20621 closed defect (bug) (duplicate)

Unable to reach "Edit Page" screen when Wordpress admin has a few thousand pages.

Reported by: jorenrapini's profile jorenrapini Owned by:
Milestone: Priority: normal
Severity: major Version: 3.3.2
Component: Query Keywords: needs-patch
Focuses: Cc:

Description

We have a website on Wordpress 3.3.2 with around 8,000 pages on it. We've tried moving the website to multiple hosting accounts and even a server with 1GB of dedicated memory, all plugins disabled, but it seems we hit a threshold in what Wordpress is capable of serving.

Wordpress seems to be running an extremely inefficient query to serve its Pages and Page Edit admin screens. After having too many pages, these screens will simply just load forever. Wp_list_pages query seems to do something similar, that was causing any pages an extra couple of minutes to load on the front end, but once I replaced it with a custom MySQL query to produce the same results, the pages loaded instantly. I cannot do the same with the admin though :(

Change History (12)

#1 @nacin
13 years ago

  • Severity changed from blocker to major

The admin should be *significantly* improved in 3.4 due to the performance improvements to WP_Query.

#2 @duck_
13 years ago

Sounds like a duplicate of #15459.

#4 follow-up: @nacin
13 years ago

  • Component changed from Database to Query
  • Milestone changed from Awaiting Review to 3.4
  • Priority changed from normal to highest omg bbq
  • Severity changed from major to blocker

I think the changes in 3.4 could actually cause a segfault here due to too long of a query string. We might need to opt-out of our query-splitting code if we don't have a LIMIT on the query or if the limit is > X items.

#5 in reply to: ↑ 4 @ryan
13 years ago

Replying to nacin:

I think the changes in 3.4 could actually cause a segfault here due to too long of a query string. We might need to opt-out of our query-splitting code if we don't have a LIMIT on the query or if the limit is > X items.

That seems sensible for 3.4.

#6 @jorenrapini
13 years ago

  • Severity changed from blocker to major

If it helps, I did just give 3.4 beta 3 a shot and it didn't make a difference to this specific problem.

#7 @jorenrapini
13 years ago

  • Severity changed from major to blocker

#8 @jorenrapini
13 years ago

Since you guys know Wordpress' database structure much better than I, as a bandaid I was considering splitting this up about 75 ways into separate Wordpress multisites. So, I'd have around 100 pages per network site - would this help temporarily fix the problem since they'd be on separate wp_post tables?

#9 @kovshenin
13 years ago

  • Cc kovshenin@… added

#10 @ryan
13 years ago

Note that we're not going to fix the performance issues for 3.4. We're just going to remove the segfault potential introduced in 3.4.

A possible workaround is to turn off hierarchical display in edit.php. A filter in wp_edit_posts_query() might be able to accommodate this.

#11 @ryan
13 years ago

Created a new ticket for the query split. #20628

#12 @nacin
13 years ago

  • Milestone 3.4 deleted
  • Priority changed from highest omg bbq to normal
  • Resolution set to duplicate
  • Severity changed from blocker to major
  • Status changed from new to closed

Duplicate of #15459 and #20628 then.

Note: See TracTickets for help on using tickets.