Remove or cache call to system_status [#2455657]

When accessing the shop administration page, there's this code (in uc_store.admin.inc):

  if (system_status(TRUE) && user_access('administer site configuration')) {
    drupal_set_message(t('One or more problems were detected with your Drupal installation. Check the <a href="@status">status report</a> for more information.', array('@status' => url('admin/reports/status'))), 'error');
  }

Calling system_status() on big sites is big words. Unluckily CORE does not cache the results of system_status() internally (and that is not bad at all).

Some modules even implement network calls inside the status page (for example mollom checking for valid API keys, advanced aggregation checking for server statuses, etc...).

On some sites I've seen system_status being 80% of all page time when accesing the shop administration page.

But I don't like caching either, system_status is supposed to be realtime status of the site....

Comment	File	Size	Author
#3	2455657-slow-admin-page.patch	1.74 KB	david_garcia
#3	7.x-3.x: PHP 5.3 & MySQL 5.5, D7 125 pass

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

TR CreditAttribution: TR commented 19 March 2015 at 20:39

Category:	Bug report	» Feature request
Priority:	Major	» Normal

The assumption is that the store manager, the one who does the day-to-day processing of orders, may not be the same person as the website developer. And in fact we want Ubercart to be usable by small businesses - we don't want to require a dedicated IT department just to install/configure/manage a store site. The store manager will look at /admin/store every day, but probably won't ever see /admin/reports/status. So how to we keep the store manager informed of things like core security updates or cron failing (thus causing store-related things to fail silently), etc. ?

Is CPU usage on the /admin/store page really a big problem, or are you more concerned about the time it takes to render a page? I don't like the idea of Maybe a smart caching scheme, where the system_status() is checked via hook_cron() and the result saved in a system variable, then we could just check the system variable before printing the message on /admin/store. This would still require cron to be properly set up and run frequently (every 15 minutes? every hour?) so we would still need a real-time indicator of whether cron was working properly.

Comment #2

david_garcia CreditAttribution: david_garcia commented 19 March 2015 at 20:51

I understand the point... it's not a matter of CPU, but having to wait 6-9 seconds on a page that will normaly load instantly is not good.

Maybe it would be easy to cache the results with a fixed expiration (1 day?) so it will be slow only on first load. With that approach there's no need to run cron, and will still server the purpose of keeping small business store admins updated.

Ideally, if everything is OK with the status, the cache can be longer (1 day) but if there's something wrong set it to 1 hour.

BTW... user_access('administer site configuration') should go before system_status(TRUE) in the if statement, so if the user is cannot admin the site at least all the system_status checks are not triggered.