I first found this issue in a Drupal 7 site I help maintain. I will use Drupal 8 dev line numbers below. It is not a bug, but a performance issue question.
Symptom: Any time an /admin page was accessed, I noticed the page load times could be 2-5 seconds, compared to other pages that were about a second.
After a lot of digging, I found the function update_page_build() in update.module (line 96) which makes the decision on whether to show the message or not. The switch statement has no default case. This means that any /admin page not in the first list ('additional nagging'), will always show the message.
While I understand wanting to display the nag message as often as possible, it seems a little excessive to slow down almost all of the /admin pages figuring out if the message should be displayed.
"Why is it so slow?" you ask. I tracked it down two factors: The number of modules on the site and the progressive slowness of an array_merge() function call in file_scan_directory() in file.inc (line 1197).
By the time file_scan_directory() gets done, it's cataloged 256 elements. I don't know if that is a lot, but it's at the top end for us.
In my limited understanding, array_merge() tends to get progressively slower the more elements are in the array.
My temporary solution is to change the switch statement to include a default case like this:
switch (current_path()) {
// These pages don't need additional nagging.
case 'admin/appearance/update':
case 'admin/appearance/install':
case 'admin/modules/update':
case 'admin/modules/install':
case 'admin/reports/updates':
case 'admin/reports/updates/update':
case 'admin/reports/updates/install':
case 'admin/reports/updates/settings':
case 'admin/reports/status':
case 'admin/update/ready':
return;
// If we are on the appearance or modules list, display a detailed report
// of the update status.
case 'admin/appearance':
case 'admin/modules':
$verbose = TRUE;
break;
default:
return;
}
This allows the nag message to only be displayed on admin/appearance and admin/modules pages. Perhaps this could be a configurable decision.
Another possible solution would be to replace the array_merge() in file.inc with another faster function. Example: http://www.bitbybit.dk/carsten/blog/?p=203
Just a thought...
Comments
Comment #1
dpearcefl CreditAttribution: dpearcefl commentedAfter talking with a few people on #drupal IRC, I seem to not be the only one concerned by the slowness of the update module. Some people advocated just turning the module off to deal with the slowness. While effective, it also negates the update check completely.
I'd like to see some reactions from the core devs on this issue.
Comment #3
cilefen CreditAttribution: cilefen commentedComment #11
apadernoDrupal 8.9.x is now open only to security issues.
Comment #12
cilefen CreditAttribution: cilefen commentedIt would be useful to profile the performance of the suggested solution vs that of the main branch.