Interestingly enough, it doesn't seem to be affecting all of our nodes, but a certain node cannot render the "Moderation" tab. It hangs for several seconds (30) and then fails.

error_log says:

[Mon Feb 24 15:30:09 2014] [error] [client 131.252.85.34] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /home/..../modules/system/image.gd.inc on line 237, referrer:

Some details:

Workbench ver 7.x-1.2
Workbench Access ver 7.x-1.2
Workbench Moderation ver 7.x-1.3

Thoughts or suggestions?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

laughnan’s picture

A temporary solution is to edit the php.ini file and set max_execution_time = 300.

I recommend maybe only loading the top 10 last moderations rather than loading every since moderation (thereby causing a longer execution time). I might look into updating some of our code to see the results.

laughnan’s picture

Status: Active » Needs work

This issue needs to be addressed. Working on a patch that either limits the query result or creates some notion of pages.

laughnan’s picture

Version: 7.x-1.3 » 7.x-1.4
laughnan’s picture

This isn't the best (and probably wouldn't be something to contribute back), but at least we set a limit on the query. I think an ultimate goal would be to create pagination around this.

don.bliss@edmentum.com’s picture

bump.

jamesrward’s picture

Just hit this issue on a site I am working on and it's quite troubling. The max execution time on the server (Acquia Cloud) is already at 300 so the resources used to hit this error where pretty huge and caused a serious slow-down. The page has a large number of drupal hosted files linked within the body and changes frequently. Even using the patch from #4 I had to crank the range down to 8 to get the moderation page to load. I think paging the results is a good first step towards avoiding this issue but I worry there is something fundamentally wrong with the way workbench moderation loads entities for the non-published versions of a page. I will do some more investigating and post back but my initial cachegrind showed more than 15K calls to entity_load for the moderation of this page.

iStryker’s picture

15 000 calls does not sound good. Maybe caching a function will help. I am curious though, how many revisions are there for that node.

I did not work on this directly, but I think we had this problem at the University of Waterloo. Our solution was to only keep the last 50 revisions. We used node https://www.drupal.org/project/node_revision_delete to do this.

jamesrward’s picture

Status: Needs work » Closed (duplicate)
Related issues: +#1408838: Node revision history optimization on large websites

This patch currently on dev fixed things for us. We go from 11 minute load time to less than 1 second on one of our worst offending pages. I'm marking as a duplicate.

laughnan’s picture

This is amazing @jamesrward!