[wp-trac] [WordPress Trac] #9864: Performance issues with large number of pages

[WordPress Trac]

#9864: Performance issues with large number of pages
----------------------------+-----------------------------------------------
 Reporter:  pp19dd          |       Owner:             
     Type:  defect (bug)    |      Status:  new        
 Priority:  normal          |   Milestone:  Unassigned 
Component:  Administration  |     Version:  2.7.1      
 Severity:  normal          |    Keywords:  2nd-opinion
----------------------------+-----------------------------------------------
 '''Environment:'''

 - Default install, default theme, no plugins, reasonable server
 configuration (typical execution, memory limits).  In my particular case,
 that was set to 30 seconds, 384 MB.

 '''To reproduce:'''

 - Create a large number of pages (5,000+)[[BR]]
 - Try to edit a page

 '''What happens:'''

 - Maximum execution time error

 {{{
 Fatal error: Maximum execution time of 30 seconds exceeded in \wp-
 includes\post.php on line 1998
 }}}

 '''Workaround to prevent error:'''

 - set_time_limit to 0 as server admin

 '''My diagnosis:'''

 Suspect that the immediate problem is that get_pages() inside wp-
 admin/post.php, line 2173,  performs a query that selects EVERYTHING:

 {{{
 $query = "SELECT * FROM $wpdb->posts $join WHERE (post_type = 'page' AND
 post_status = 'publish') $where ";
 }}}

 Now, in this case this query (AFAIK) is just supposed to pull up the page
 list (with IDs, titles and parents).  What it actually does is it pulls up
 ALL of the post data.  This works fine for low number of pages, but on a
 larger data set this causes a chokepoint.  After all, the end result is
 just supposed to be a dropdown with a list of pages.


 '''Workaround to improve performance:'''

 - comment out line 273 in wp-admin\edit-page-form.php and skip displaying
 the page parent in the edit screen

 '''The bigger picture:'''

 Well, the ENTIRE list of pages is queried in this 'edit page' screen (see
 screenshot # 2 - with a dropdown that contains 5,000+ entries.)  I think
 this is a design limitation and it looks clumsy once the list gets larger.
 Rather than patch the display routines, I think this thing needs to be
 replaced with something that can search / paginate piecemeal server-side.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/9864>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software