Page MenuHomePhabricator

Slow log in - looks like it's drupal cron
Open, Needs TriagePublic


As I think we are all aware my efforts to speed up CiviCRM logins have only been partially successful. There is still a lag. I did a bit more digging today & I think it is the drupal cron running as a poor-man's cron.

I think if we can confirm the cron is otherwise running on staging & prod we can disable the poor man's cron & rely on scheduled crons.

I've just disabled it on staging but probably there is no other cron running on there (@Jgreen @cwdent - is there a cron on staging running the drupal cron). It looks like the command is

drush cron

Disabling "automated cron"
For performance reasons, or if you want to ensure that cron can only ever run from an external trigger, it may be desirable to disable the automated cron system.

You can disable it by setting the "Run cron every" value to "Never" (e.g., at Administration > Configuration > System > Cron (admin/config/system/cron).

Alternatively, in Drupal 7, you can set the 'cron_safe_threshold' variable in the {variable} table to 0. (Note that drush will assume this variable is 0 if you have left the "Run cron every" value at the default, so you will need to set it explicitly, either at admin/config/system/cron, or via drush -y vset cron_safe_threshold 0)

Another way to disable cron in Drupal 7 is to add the following line to your settings.php:
$conf['cron_safe_threshold'] = 0;

Note that this fixes the setting at admin/config/system/cron to "Never", and administrative users cannot override it.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 11 2017, 4:12 AM

System cron doesn't call drush in any way.

IMHO the settings.php approach is best, since that's visible in version
control for localsettings.

OK - so we need to get it running on staging by some sort of cron & then we can leave it off. On live we can set up a jenkins job & then turn it off

I pulled this in since I'm working on jenkins jobs now it's a good time to turn on cron again

I've just added a cron in jenkins. The setting may not be necessary with the cron on - I just trying logging in shortly after the cron ran. @LeanneS @MBeat33 @RLewis @CaitVirtue - I just tried something that improved the first login time of the day for me - let me know what your experience is over the next few days

I timed the load time for my first log in this morning. I'm WFH. It took 52 seconds.

I had closed all my Civi tabs about 5 min ago, and then just tried to open up a new one (6:04pm local time). It took 49 seconds to load. It had loaded fairly quickly all day, up until this point.

Mentioned in SAL (#wikimedia-fundraising) [2017-01-30T20:25:58Z] <eileen1> disable drupal update module on prod. T155084, this should still be on on dev sites so not using update script

OK I tried logging in just now & it was quick but as soon as I went to a page with 'admin' in the url it was slow.

It looks like it was not running cron on my first login, but still running update when navigating to an admin page. I have now disabled the update module on production. It was not working, due to the firewall so there is no loss there. I did not do it in an update script as local instances should still run it.

I have also added a settings.php change to disable poor man's cron per other comments

31 second load this this morning, from the office

37 second load time this morning, in the office.

Load time at 4:26pm PST, in the office, 46 seconds

@Eileenmcnaughton Is this useful? Should I keep going? Stop?

I think you can stop for now - I am experience faster load on some screens now but am also experiencing slow load on the main CiviCRM page - so test again once I have managed to get some improvement that I can see.

The issue is something trying to do http communication & being blocked by our firewall - but I'm not quite sure what

@DStrine we should pull this back in soon

Aklapper removed Eileenmcnaughton as the assignee of this task.Jun 19 2020, 4:14 PM

This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)