Answers.Body: <p>There are several things happening on the dashboard, so you'll need to dig further into this yourself to find the real underlying issue. Here are some things which could trigger symptoms like what you're describing.</p>
  
  <h2>Database warmup</h2>
  
  <p>This is the most common cause of slow dashboards IMO, but it's dependent on your setup; see note re Timeouts below.</p>
  
  <p>Your DB engine keeps frequently used data in memory. When CiviCRM isn't being actively used overnight, that information will be replaced in memory by other data, and will be read from disk. This is slower. (Nightly DB backups frequently push active daily data from memory, as does a changed traffic profile when your staff knock off.)</p>
  
  <p>We have a testing server which hosts multiple WIP databases. It mirrors your description; starting work on Site A will incur a few seconds (or longer) "warm-up" time. This suggests that the server is overloaded (for production use!).</p>
  
  <p>A workaround is to log into the site earlier, before your morning call / coffee brew / whatever. If we know we're working on example.com and example.org today, we can <code>drush uli</code> and visit <code>/civicrm</code> on both sites before we kick off for the day. Moving a delay can make it disappear :)</p>
  
  <p>The ideal solution is to make more memory available to MySQL. Buying memory is probably cheaper than the (admin, staffing) cost of dealing with insufficient memory. :)</p>
  
  <h2>Timeouts</h2>
  
  <p>If reproducible, a specific five minute time as seen in your screenshot suggests you're hitting a timeout. This is compatible with the next answer, provided that you have a slow dashboard report which takes more than five minutes, so you reliably hit that timeout. </p>
  
  <ul>
  <li>You request the CiviCRM dashboard</li>
  <li>CiviCRM internally requests a report</li>
  <li>Report spins its wheels for (at least) five minutes</li>
  <li>CiviCRM stops waiting and serves you the dashboard minus that report.</li>
  </ul>
  
  <p>Observing a predictable delay (=timeout) <em>then</em> a successful response from the server (as opposed to a predictable delay followed by error message from server, or a predictable delay then error message from the browser) indicates that the timeout is happening internally to CiviCRM.</p>
  
  <p>A five minute timeout could be configured at different layers, in your webserver (eg PHP <code>max_execution_time</code>, apache <code>TimeOut</code>) or in CiviCRM codebase (eg cURL's <code>CURLOPT_TIMEOUT</code>). You don't really want to change the timeout, you want to speed up that process so it doesn't hit the timeout!</p>
  
  <h2>Dashboard reports</h2>
  
  <p>The dashboard is user-customisable, so the reports you choose to show there will affect the time it takes to display. Because the dashboard contents are delivered as a single page to the admin, you can't see which report is fast or slow. Disabling some reports, or observing the internal requests made from CiviCRM (by watching your weblogs) might allow you to see which reports add the load time to the dashboard.</p>
  
  <p>To identify these dashboard report loads in the webserver logs, look for <code>POST</code> requests to <code>/civicrm/ajax/dashboard</code> immediately before your <code>GET</code> request for <code>/civicrm/dashboard?reset=1</code> is completed. Timing on those requests will indicate if they are the delay factor.</p>
  
  <p>Check MySQL activity too - I use <a href="http://jeremy.zawodny.com/mysql/mytop/"><code>mytop</code></a>, which is just MySQL's <code>SHOW FULL PROCESSLIST</code> as a command. If you see long-running queries generating reports, you can balance whether to improve the report, remove it from your dashboard, or accept that it's worth the wait.</p>
  
  <h2>Reports using memberships / smart groups</h2>
  
  <p>If dashboard reports include smart groups or memberships, remember that memberships get updated daily (by cron), and that smart group caching is only for a limited time. Such reports would need to be regenerated the first time they are run after midnight. CiviCRM includes functionality to schedule report generation, so you could keep your contact DB warmed up (or on the boil!) by scheduling a report to display before you start work, or perhaps by embedding the same dashboard reports on a public screen in your office :)</p>
  
  <h2>URL / webserver configuration</h2>
  
  <p>CiviCRM makes internal requests while delivering the dashboard as well. Slow performance here could be indicative of a misconfiguration, eg:</p>
  
  <ul>
  <li>CiviCRM is unable to communicate with the local site</li>
  <li>CiviCRM is unable to communicate with CiviCRM.org infrastructure</li>
  <li>DNS on the webserver is slow or incorrectly configured</li>
  </ul>
  
  <p>Issues with these <em>should</em> trigger warnings on the admin screen which you would likely have mentioned, but it's worth checking that too. These warnings can be disabled, which might work to hide the symptoms.</p>
  
  <h2>Requests to CiviCRM.org</h2>
  
  <p>As above - CiviCRM communicates with CiviCRM.org while loading the dashboard. This functionality can be disabled (can't it?), but if doing so was working but slow or slow to return an error, you'd see a delay in rendering the dashboard also. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-09T20:42:23.193Z
Answers.Text: Kudos to you, Chris. This answer is gold.
Answers.UserDisplayName: Allen Hutchison
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-12T19:46:54.803Z
Answers.Text: Nicely comprehensive! But 5 minutes is such a long time, I'd bet my money on some kind of network issue (i.e. your URL/webserver configuration, or maybe something a little further down). Some kind of proxying setup, e.g. for outgoing http requests from the server would be a prime suspect.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-09T19:38:37.770Z
Answers.LastActivityDate: 2016-04-10T20:27:43.503Z
Answers.LastEditDate: 2016-04-10T20:27:43.503Z
Answers.UserDisplayName: Chris Burgess
Answers.Body: <p>Thank you for all your suggestions. The culprit was a lousy .htaccess in the civicrm/ConfigAndLog folder. It contained a  directive that prevented civi to access logs.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-22T19:48:14.010Z
Answers.Text: That's intentional, CiviCRM is checking that users from the web should not be able to access logfiles over HTTP.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-04T19:38:23.127Z
Answers.Text: @damien I'd file a bug rep to put a temp limit of 20s on just this check. Then sub a patch.
Answers.UserDisplayName: JohnFF
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-22T13:07:08.530Z
Answers.LastActivityDate: 2016-04-22T13:07:08.530Z
Answers.UserDisplayName: Damien
Answers.Body: <p>This could be due to cron not running.  Have you set up a cron job?  If not, the CMS (content management system) may run maintenance tasks when you first access the site in the morning.</p>
  
  <p>If you are using Drupal you can find more information here: <a href="https://www.drupal.org/cron" rel="nofollow">Setting up cron</a>.</p>
  
  <p>You will also need to use cron to run scheduled jobs in CiviCRM - see <a href="https://wiki.civicrm.org/confluence/display/CRMDOC/Managing+Scheduled+Jobs" rel="nofollow">Managing Scheduled Jobs</a>.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-08T13:01:58.427Z
Answers.Text: No. The CMS cron runs normally and the CMS itself behaves normally. It's accessing the dashboard that is really slow at first use
Answers.UserDisplayName: Damien
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-08T10:56:09.357Z
Answers.LastActivityDate: 2016-04-08T10:56:09.357Z
Answers.UserDisplayName: William Mortada
Body: <p>We have a two domains civicrm setup. On the first domain, everything is normal but on the second one, it takes dozens of seconds to open the dashboad (/civicrm) on the first daily use on every computer.</p>
  
  <p>I can't reproduce the issue if I use a link other that the one that opens the dashboard</p>
  
  <p>Resource URL are absolute.</p>
  
  <p>see below: 5 minutes waiting to display civicrm?reset=1</p>
  
  <p><a href="https://i.sstatic.net/9BSfd.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/9BSfd.png" alt="enter image description here"></a></p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-04-08T10:56:20.497Z
Comments.Text: It would be helpful if you could include the version of CiviCRM you are using and the type and version of the CMS you are using (e.g. WordPress, Drupal or Joomla).
Comments.UserDisplayName: William Mortada
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-04-08T12:56:38.410Z
Comments.Text: sorry about that. It's running on drupal 7.43 / civi 4.7.4
Comments.UserDisplayName: Damien
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-04-09T07:45:40.230Z
Comments.Text: Do you have anything set to display on the dashboard? Perhaps a report that filters on a smart group?
Comments.UserDisplayName: JoAnne
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-03-04T10:07:23.343Z
Comments.Text: I am seeing this same problem. Damien, can you tell us how you solved it, because I tried removing that .htaccess file and CiviCRM just writes a new one. Also, why doesn't CiviCRM just tell us what it's doing during this big long delay? Isn't there a way to turn on debug mode or logging that would indicate what is causing the delay? Thanks
Comments.UserDisplayName: feralfruitfreak
Tags: <dashboard>
Title: Slow to open at first daily use
ThreadText: # Slow to open at first daily use
  
  (Asked by: username_0 on 2016-04-08)
  
  We have a two domains civicrm setup. On the first domain, everything is normal but on the second one, it takes dozens of seconds to open the dashboad (/civicrm) on the first daily use on every computer.
  
  I can't reproduce the issue if I use a link other that the one that opens the dashboard
  
  Resource URL are absolute.
  
  see below: 5 minutes waiting to display civicrm?reset=1
  
  [![enter image description here](https://i.sstatic.net/9BSfd.png)](https://i.sstatic.net/9BSfd.png)
  
  **Tags:** dashboard
  
  > **Comments:**
  > **username_1**: It would be helpful if you could include the version of CiviCRM you are using and the type and version of the CMS you are using (e.g. WordPress, Drupal or Joomla).  
  > **username_0**: sorry about that. It's running on drupal 7.43 / civi 4.7.4  
  > **username_2**: Do you have anything set to display on the dashboard? Perhaps a report that filters on a smart group?  
  > **username_3**: I am seeing this same problem. username_0, can you tell us how you solved it, because I tried removing that .htaccess file and CiviCRM just writes a new one. Also, why doesn't CiviCRM just tell us what it's doing during this big long delay? Isn't there a way to turn on debug mode or logging that would indicate what is causing the delay? Thanks  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_4 on 2016-04-09. Score: 7
  
  There are several things happening on the dashboard, so you'll need to dig further into this yourself to find the real underlying issue. Here are some things which could trigger symptoms like what you're describing.
  
  ## Database warmup
  
  This is the most common cause of slow dashboards IMO, but it's dependent on your setup; see note re Timeouts below.
  
  Your DB engine keeps frequently used data in memory. When CiviCRM isn't being actively used overnight, that information will be replaced in memory by other data, and will be read from disk. This is slower. (Nightly DB backups frequently push active daily data from memory, as does a changed traffic profile when your staff knock off.)
  
  We have a testing server which hosts multiple WIP databases. It mirrors your description; starting work on Site A will incur a few seconds (or longer) "warm-up" time. This suggests that the server is overloaded (for production use!).
  
  A workaround is to log into the site earlier, before your morning call / coffee brew / whatever. If we know we're working on example.com and example.org today, we can `drush uli` and visit `/civicrm` on both sites before we kick off for the day. Moving a delay can make it disappear :)
  
  The ideal solution is to make more memory available to MySQL. Buying memory is probably cheaper than the (admin, staffing) cost of dealing with insufficient memory. :)
  
  ## Timeouts
  
  If reproducible, a specific five minute time as seen in your screenshot suggests you're hitting a timeout. This is compatible with the next answer, provided that you have a slow dashboard report which takes more than five minutes, so you reliably hit that timeout.
  
  * You request the CiviCRM dashboard
  * CiviCRM internally requests a report
  * Report spins its wheels for (at least) five minutes
  * CiviCRM stops waiting and serves you the dashboard minus that report.
  
  Observing a predictable delay (=timeout) *then* a successful response from the server (as opposed to a predictable delay followed by error message from server, or a predictable delay then error message from the browser) indicates that the timeout is happening internally to CiviCRM.
  
  A five minute timeout could be configured at different layers, in your webserver (eg PHP `max_execution_time`, apache `TimeOut`) or in CiviCRM codebase (eg cURL's `CURLOPT_TIMEOUT`). You don't really want to change the timeout, you want to speed up that process so it doesn't hit the timeout!
  
  ## Dashboard reports
  
  The dashboard is user-customisable, so the reports you choose to show there will affect the time it takes to display. Because the dashboard contents are delivered as a single page to the admin, you can't see which report is fast or slow. Disabling some reports, or observing the internal requests made from CiviCRM (by watching your weblogs) might allow you to see which reports add the load time to the dashboard.
  
  To identify these dashboard report loads in the webserver logs, look for `POST` requests to `/civicrm/ajax/dashboard` immediately before your `GET` request for `/civicrm/dashboard?reset=1` is completed. Timing on those requests will indicate if they are the delay factor.
  
  Check MySQL activity too - I use [`mytop`](http://jeremy.zawodny.com/mysql/mytop/), which is just MySQL's `SHOW FULL PROCESSLIST` as a command. If you see long-running queries generating reports, you can balance whether to improve the report, remove it from your dashboard, or accept that it's worth the wait.
  
  ## Reports using memberships / smart groups
  
  If dashboard reports include smart groups or memberships, remember that memberships get updated daily (by cron), and that smart group caching is only for a limited time. Such reports would need to be regenerated the first time they are run after midnight. CiviCRM includes functionality to schedule report generation, so you could keep your contact DB warmed up (or on the boil!) by scheduling a report to display before you start work, or perhaps by embedding the same dashboard reports on a public screen in your office :)
  
  ## URL / webserver configuration
  
  CiviCRM makes internal requests while delivering the dashboard as well. Slow performance here could be indicative of a misconfiguration, eg:
  
  * CiviCRM is unable to communicate with the local site
  * CiviCRM is unable to communicate with CiviCRM.org infrastructure
  * DNS on the webserver is slow or incorrectly configured
  
  Issues with these *should* trigger warnings on the admin screen which you would likely have mentioned, but it's worth checking that too. These warnings can be disabled, which might work to hide the symptoms.
  
  ## Requests to CiviCRM.org
  
  As above - CiviCRM communicates with CiviCRM.org while loading the dashboard. This functionality can be disabled (can't it?), but if doing so was working but slow or slow to return an error, you'd see a delay in rendering the dashboard also.
  
  > **Comments:**
  > **username_5**: Kudos to you, Chris. This answer is gold.  
  > **username_6**: Nicely comprehensive! But 5 minutes is such a long time, I'd bet my money on some kind of network issue (i.e. your URL/webserver configuration, or maybe something a little further down). Some kind of proxying setup, e.g. for outgoing http requests from the server would be a prime suspect.  
  
  ---
  
  ### Answer by username_0 on 2016-04-22. Score: 2
  
  Thank you for all your suggestions. The culprit was a lousy .htaccess in the civicrm/ConfigAndLog folder. It contained a directive that prevented civi to access logs.
  
  > **Comments:**
  > **username_4**: That's intentional, CiviCRM is checking that users from the web should not be able to access logfiles over HTTP.  
  > **username_7**: @damien I'd file a bug rep to put a temp limit of 20s on just this check. Then sub a patch.  
  
  ---
  
  ### Answer by username_1 on 2016-04-08. Score: 1
  
  This could be due to cron not running. Have you set up a cron job? If not, the CMS (content management system) may run maintenance tasks when you first access the site in the morning.
  
  If you are using Drupal you can find more information here: [Setting up cron](https://www.drupal.org/cron).
  
  You will also need to use cron to run scheduled jobs in CiviCRM - see [Managing Scheduled Jobs](https://wiki.civicrm.org/confluence/display/CRMDOC/Managing+Scheduled+Jobs).
  
  > **Comments:**
  > **username_0**: No. The CMS cron runs normally and the CMS itself behaves normally. It's accessing the dashboard that is really slow at first use  
  
  ---
  
  