1

I have an issue where the first CiviCRM request of any session takes 4 minutes to load. This can be a request for the dashboard, or an administrative screen, it doesn't matter. There are no errors on screen and no errors appearing in the CiviCRM runtime logs. The first pageload simply takes four minutes, then everything works fine -- until the user logs out, and logs in again. Then the first request takes another 4 minutes.

I've been trying to research this and have come across several other questions that are relevant but don't exactly match my situation (Slow to open at first daily use, https://civicrm.stackexchange.com/questions/12886/civicrm-dashboard-hangs-for-5-minutes?rq=1,https://civicrm.stackexchange.com/questions/14343/civicrm-dashboard-hangs-for-5-minutes-part-2?noredirect=1&lq=1)

Based on info in the many answers, I've discovered the following:

  • removing all dashlets/reports from the dashboard doesn't improve speed. Dashboard still takes 4 minutes to load -- but so do the other requests (except, strangely, for searches, which load right up)
  • hosting provider has confirmed we don't have a NAT Fire setup and that internal requests should be working normally
  • database doesn't seem to be the issue because 1) it's not maxed out, and 2) 2 concurrent sessions making the same requests one after the other exhibit the same behavior

I'm pretty sure this is an environment problem, because I have two CiviCRM installs on the same server which are exhibiting the same behavior (two different versions: 4.7.24 and 4.7.29). Clones of these environments do not have this problem on my local test servers.

It smells like a timeout, but I just can't for the life of me figure out where to start looking for what is timing out, and why only on the FIRST request of a session!

Seen in two installs of CiviCRM on the same server:

1st: Joomla 3.6.5, CiviCRM 4.7.24, PHP 5.6 2nd: Joomla 2.5.28, CiviCRM 4.7.29, PHP 5.6

Improve this question
2
  • OK so I also found this post (civicrm.stackexchange.com/questions/8293/…) which looked promising, but no joy. Had my hosting company swap out mpm_worker with mpm_event but the same timeout occurs.
    – minbori
    Jan 4, 2018 at 18:28
  • Another suggestion in the above post -- CiviCRM security checks? It makes sense these would happen only once per session, so are they making a request that times out? Why does CiviCRM just ignore it and continues running normally, throwing no errors or warnings? I'm just not even sure where I start looking for this :-/
    – minbori
    Jan 4, 2018 at 18:37

3 Answers 3

Reset to default
2

I had a lot of trouble tracking down a problem that sounds the same. We ARE behind a firewall so pingbacks to CiviCRM etc WILL timeout. The last piece of the puzzle (once normal version checks were disabled) was adding this to civicrm.settings.php

global $civicrm_setting; $civicrm_setting['CiviCRM Preferences']['communityMessagesUrl'] = FALSE;

Improve this answer
1

To test whether the checks are causing the problem, open this file in your CiviCRM root: CRM/Utils/Check.php. Right at the top (line 35 or so) you'll see this:

const CHECK_TIMER = 86400;

Change that number to something lower (like 1) and save. If the problem starts happening on every page load, the problem is the CiviCRM checks, and you can try disabling certain checks. Note that setting the number low WILL cause some performance issues generally - but not 4 minutes per page load.

Improve this answer
12
  • Interesting! So, changing that CHECK_TIMER value brought all page loads up to 3 minutes. So it seems there is a check somewhere that is timing out silently after which things function. Where exactly are the checks that I can start disabling to see which is causing the problem? It doesn't seem like the checks in the CRM/Utils/Check.php file would be causing any network timeout issues.
    – minbori
    Jan 11, 2018 at 14:21
  • EDIT: I think I've found them -- basically all the classes under CRM/Utils/Check/ , correct? Or is there somewhere else I also need to look?
    – minbori
    Jan 11, 2018 at 14:37
  • @minbori that's correct. Note also there's a hook, hook_civicrm_check. You may want to grep for civicrm_check in your extensions directory.
    – Jon G - Megaphone Tech
    Jan 11, 2018 at 18:19
  • Thanks again, Jon. Well I've gotten to the point where I've found exactly WHAT is timing out in the checks, now we're searching for WHY. It's @get_headers() and @file_get_contents() requests in these files: File: [civi.root]/administrator/components/com_civicrm/civicrm/CRM/Utils/Check/Component/Env.php File: [civi.root]/administrator/components/com_civicrm/civicrm/CRM/Utils/Check/Component/Security.php
    – minbori
    Jan 15, 2018 at 13:56
  • uugh, I'm so sorry I ever wrote that check. Please see this question: civicrm.stackexchange.com/questions/21925/…
    – Jon G - Megaphone Tech
    Jan 15, 2018 at 21:37
0

A similar issue I've seen manifests when your CMS doesn't have a proper cron set up. I can't speak to Joomla, but WordPress and Drupal can both run their scheduled jobs on a page load. It's worth considering if your slowness is possibly related to the CMS and not CiviCRM.

This one is tricky, because sometimes it seems like it's host-specific - but the truth is that they're test sites that don't get traffic. The live site doesn't manifest this issue because the scheduled jobs are spread out over more page loads.

Improve this answer
2
  • Interesting. Thanks for the idea; I think our CRONs are set up but I'll check.
    – minbori
    Jan 11, 2018 at 13:52
  • Also, the problem manifests on live sites, not on my test ones -- the test sites get no traffic and don't have this problem.
    – minbori
    Jan 11, 2018 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.