Answers.Body: <p>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</p>
  
  <p>global $civicrm_setting;
    $civicrm_setting['CiviCRM Preferences']['communityMessagesUrl'] = FALSE;</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-10T04:15:06.377Z
Answers.LastActivityDate: 2018-04-10T04:15:06.377Z
Answers.UserDisplayName: user4278
Answers.Body: <p>To test whether the checks are causing the problem, open this file in your CiviCRM root: <code>CRM/Utils/Check.php</code>.  Right at the top (line 35 or so) you'll see this:</p>
  
  <pre><code>const CHECK_TIMER = 86400;
  </code></pre>
  
  <p>Change that number to something lower (like <code>1</code>) 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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-11T14:21:49.737Z
Answers.Text: 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.
Answers.UserDisplayName: minbori
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-11T14:37:11.813Z
Answers.Text: 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?
Answers.UserDisplayName: minbori
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-11T18:19:04.440Z
Answers.Text: @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.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-15T13:56:04.263Z
Answers.Text: 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
Answers.UserDisplayName: minbori
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-15T21:37:54.057Z
Answers.Text: uugh, I'm so sorry I ever wrote that check.  Please see this question: https://civicrm.stackexchange.com/questions/21925/incorrect-resource-url-warning-but-menu-arrows-are-present
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-15T21:38:38.910Z
Answers.Text: Basically - CiviCRM is loading web content from itself.  Your server is most likely configured to block connections from itself, probably unintentionally.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-18T10:11:12.630Z
Answers.Text: That's what I thought too, and was the original info I found in the research I did. However, my host swears up and down that our server is not blocking connections from itself.  I'll need to figure out how to test that independently.  EDIT: I just read the post at the link you gave me, and see there's a check there.  Off to do it....
Answers.UserDisplayName: minbori
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-18T15:36:58.933Z
Answers.Text: OK so netcat test was successful -- no problem connecting from the command line.  And I even shut off our CSF firewall completely just to see if it was the problem.  Nope, get_headers still times out.  I'm really tearing my hair out on this one -- close to just coding out the security checks -- though I hate hack core files :-(
Answers.UserDisplayName: minbori
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-18T16:07:33.247Z
Answers.Text: If after the line `$headers = get_headers($arrowUrl);` you add: `CRM_Core_Error::debug_var('headers', $headers);` do you get an array in your logs, or `FALSE`?  If you get an array, could you update the question with its contents?
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-18T16:09:53.127Z
Answers.Text: Also, have you applied the fix from CRM-21629?
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-22T12:15:59.223Z
Answers.Text: Hey Jon, thanks again for keeping with me on this! :-)  No, I hadn't seen that ticket yet, sounds like it's the perfect workaround for my issue.  I will give it a try.  Meanwhile, it seems it's a bug in CageFS that's blocking the internal requests!  We've escalated this to CageFS developers, and it seems they're going to patch it. Once we test I'll put that down as the answer.
Answers.UserDisplayName: minbori
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-22T12:20:48.253Z
Answers.Text: And to answer your question John, CRM_Core_Error::debug_var('headers', $headers); there returns "FALSE".  The internal requests just really aren't resolving. Also, just for grins, I tried requests to external sites there and they returned proper arrays.
Answers.UserDisplayName: minbori
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-08T20:10:20.883Z
Answers.LastActivityDate: 2018-01-08T20:10:20.883Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.Body: <p>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.</p>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-11T13:52:48.447Z
Answers.Text: Interesting. Thanks for the idea; I think our CRONs are set up but I'll check.
Answers.UserDisplayName: minbori
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-11T13:57:46.253Z
Answers.Text: Also, the problem manifests on *live* sites, not on my test ones -- the test sites get no traffic and don't have this problem.
Answers.UserDisplayName: minbori
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-08T20:14:22.543Z
Answers.LastActivityDate: 2018-01-08T20:14:22.543Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>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.</p>
  
  <p>I've been trying to research this and have come across several other questions that are relevant but don't exactly match my situation (<a href="https://civicrm.stackexchange.com/questions/11032/slow-to-open-at-first-daily-use/11061#11061">Slow to open at first daily use</a>, <a href="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&amp;lq=1">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&amp;lq=1</a>)</p>
  
  <p>Based on info in the many answers, I've discovered the following:</p>
  
  <ul>
  <li>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)</li>
  <li>hosting provider has confirmed we don't have a NAT Fire setup and that internal requests should be working normally</li>
  <li>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</li>
  </ul>
  
  <p>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.  </p>
  
  <p>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!</p>
  
  <p>Seen in two installs of CiviCRM on the same server:</p>
  
  <p>1st: Joomla 3.6.5, CiviCRM 4.7.24, PHP 5.6
  2nd: Joomla 2.5.28, CiviCRM 4.7.29, PHP 5.6</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-04T18:28:27.753Z
Comments.Text: OK so I also found this post (https://civicrm.stackexchange.com/questions/8293/full-minute-timeouts-on-first-page-load) which looked promising, but no joy. Had my hosting company swap out mpm_worker with mpm_event but the same timeout occurs.
Comments.UserDisplayName: minbori
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-04T18:37:09.593Z
Comments.Text: 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 :-/
Comments.UserDisplayName: minbori
Tags: <4.7><performance>
Title: first CiviCRM request of each session takes 4 minutes, afterwards works fine
ThreadText: # first CiviCRM request of each session takes 4 minutes, afterwards works fine
  
  (Asked by: username_0 on 2018-01-04)
  
  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/11032/slow-to-open-at-first-daily-use/11061#11061), <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
  
  **Tags:** 4.7, performance
  
  > **Comments:**
  > **username_0**: OK so I also found this post (https://civicrm.stackexchange.com/questions/8293/full-minute-timeouts-on-first-page-load) which looked promising, but no joy. Had my hosting company swap out mpm_worker with mpm_event but the same timeout occurs.  
  > **username_0**: 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 :-/  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2018-04-10. Score: 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;
  
  
  ---
  
  ### Answer by username_2 on 2018-01-08. Score: 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.
  
  > **Comments:**
  > **username_0**: 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.  
  > **username_0**: 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?  
  > **username_2**: @username_0 that's correct. Note also there's a hook, `hook_civicrm_check`.  You may want to grep for `civicrm_check` in your extensions directory.  
  > **username_0**: 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  
  > **username_2**: uugh, I'm so sorry I ever wrote that check.  Please see this question: https://civicrm.stackexchange.com/questions/21925/incorrect-resource-url-warning-but-menu-arrows-are-present  
  > **username_2**: Basically - CiviCRM is loading web content from itself.  Your server is most likely configured to block connections from itself, probably unintentionally.  
  > **username_0**: That's what I thought too, and was the original info I found in the research I did. However, my host swears up and down that our server is not blocking connections from itself.  I'll need to figure out how to test that independently.  EDIT: I just read the post at the link you gave me, and see there's a check there.  Off to do it....  
  > **username_0**: OK so netcat test was successful -- no problem connecting from the command line.  And I even shut off our CSF firewall completely just to see if it was the problem.  Nope, get_headers still times out.  I'm really tearing my hair out on this one -- close to just coding out the security checks -- though I hate hack core files :-(  
  > **username_2**: If after the line `$headers = get_headers($arrowUrl);` you add: `CRM_Core_Error::debug_var('headers', $headers);` do you get an array in your logs, or `FALSE`?  If you get an array, could you update the question with its contents?  
  > **username_2**: Also, have you applied the fix from CRM-21629?  
  > **username_0**: Hey Jon, thanks again for keeping with me on this! :-)  No, I hadn't seen that ticket yet, sounds like it's the perfect workaround for my issue.  I will give it a try.  Meanwhile, it seems it's a bug in CageFS that's blocking the internal requests!  We've escalated this to CageFS developers, and it seems they're going to patch it. Once we test I'll put that down as the answer.  
  > **username_0**: And to answer your question John, CRM_Core_Error::debug_var('headers', $headers); there returns "FALSE".  The internal requests just really aren't resolving. Also, just for grins, I tried requests to external sites there and they returned proper arrays.  
  
  ---
  
  ### Answer by username_2 on 2018-01-08. Score: 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.
  
  > **Comments:**
  > **username_0**: Interesting. Thanks for the idea; I think our CRONs are set up but I'll check.  
  > **username_0**: Also, the problem manifests on *live* sites, not on my test ones -- the test sites get no traffic and don't have this problem.  
  
  ---
  
  