Answers.Body: <p>Had this happen. I believe the cause is twofold:</p>
  <h2>FastCGI's <code>-idle-timeout</code> is set too low.</h2>
  <p>Craft is still writing to the log but Apache cuts it off since it hasn't sent the actual data yet. That's what the <code>incomplete headers</code> means.</p>
  <p>You'll might find a line like this in your config:</p>
  <pre><code>FastCgiServer /dev/shm/cadexdev-php.fcgi -idle-timeout 10
  </code></pre>
  <p>Some hosts might set it low, like 10 seconds. That could be fine for production to make sure scripts don't take a super long time, but as you've discovered <code>devMode</code> could take a little longer to run, depending on the case.</p>
  <h2>RunTasksAutomatically</h2>
  <p>The other piece is Craft does things in the background. Craft's documentation on <a href="https://craftcms.com/docs/config-settings#runTasksAutomatically" rel="nofollow noreferrer"><code>runTasksAutomatically</code></a> says:</p>
  <blockquote>
  <p>This setting should be disabled for servers running Win32, or with Apache’s mod_deflate/mod_gzip installed, where PHP’s flush() method won’t work.</p>
  </blockquote>
  <p>Some of those tasks clear caches and stuff. If they don't run, you'll get weird intermittent performance issues. Turn it off and run a <code>cron</code> job on your server periodically. We run php-fpm on both Apache and nginx and FWIW, we don't have this issue on nginx.</p>
  <h2>Increase PHP's memory</h2>
  <p>You'll also get a 500 / incomplete headers error if PHP dies because of lack of memory.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-09T16:42:26.717Z
Answers.Text: Thanks - very helpful! The idle-timeout makes sense especially since it was clearly writing a lot to the logs in decMode.
Answers.UserDisplayName: Mike
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-08T16:02:07.573Z
Answers.LastActivityDate: 2017-05-08T16:02:07.573Z
Answers.LastEditDate: 2020-06-17T08:56:27.903Z
Answers.UserDisplayName: RitterKnight
Answers.Body: <p>Well, it seems this was related to devMode. I have had no further issues with it off.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-05T21:22:19.473Z
Answers.LastActivityDate: 2017-05-05T21:22:19.473Z
Answers.UserDisplayName: Mike
Body: <p>We have an install of the latest Craft on a Nexcess shared account. By default, the account runs PHP 5.4.x. We were working on and configuring the site for about a week - no issues of any kind until today. We used the Nexcess control panel to update the PHP version to 5.6.3 (for a plugin we were going to use). After doing so, we found that saving entries or certain configuration elements in settings would take 5+ minutes to complete. We downgraded back to 5.4.x and still the behaviour persists. Unfortunately, it does not seem to be 100% consistent. I would say it happens about 90% of the time and cannot find any common thread as to when it happens and when it does not.</p>
  
  <p>Saving one entry is generating about 1.4 MB of Craft log files:</p>
  
  <p><a href="http://www.cadex-dev.ca/shop/logs/craft.log" rel="nofollow noreferrer">Craft Log 1</a></p>
  
  <p><a href="http://www.cadex-dev.ca/shop/logs/craft.log.1" rel="nofollow noreferrer">Craft Log 2</a></p>
  
  <p>Beyond the Craft logs, I don't see a php error in the PHP logs but there are these Apache errors when saving the entry:</p>
  
  <p><code>[Fri May 05 07:28:46 2017] [error] [client xx.xx.xx.xx] FastCGI: incomplete headers (0 bytes) received from server "/dev/shm/cadexdev-php.fcgi", referer: http://www.cadex-dev.ca/shop/admin/entries/multiUse/new</code></p>
  
  <p>I don't know if this is host-related. I do have a ticket open with Nexcess but am not certain if this is something specific to Craft instead?</p>
  
  <p><strong>EDIT:</strong>
  Also, a curious behaviour around this issue. If I save an entry and only wait, say, 20 seconds, quit my browser and then re-open and go to the entries page, the entry is there with the saved changes. No 5+ minute wait.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-05-05T13:09:44.273Z
Comments.Text: Just a comment for now... This was all in devmode. I took the site out of dev mode and no issues on any verison of PHP. Can anyone comment on this? Could it only be devmode and the time to write out alot of debug stuff in the Craft logs? I have worked in devmode a fair bit and never recall such slowdowns.
Comments.UserDisplayName: Mike
Tags: <php>
Title: Help! Craft issues after changing PHP version
ThreadText: # Help! Craft issues after changing PHP version
  
  (Asked by: username_0 on 2017-05-05)
  
  We have an install of the latest Craft on a Nexcess shared account. By default, the account runs PHP 5.4.x. We were working on and configuring the site for about a week - no issues of any kind until today. We used the Nexcess control panel to update the PHP version to 5.6.3 (for a plugin we were going to use). After doing so, we found that saving entries or certain configuration elements in settings would take 5+ minutes to complete. We downgraded back to 5.4.x and still the behaviour persists. Unfortunately, it does not seem to be 100% consistent. I would say it happens about 90% of the time and cannot find any common thread as to when it happens and when it does not.
  
  Saving one entry is generating about 1.4 MB of Craft log files:
  
  [Craft Log 1](http://www.cadex-dev.ca/shop/logs/craft.log)
  
  [Craft Log 2](http://www.cadex-dev.ca/shop/logs/craft.log.1)
  
  Beyond the Craft logs, I don't see a php error in the PHP logs but there are these Apache errors when saving the entry:
  
  `[Fri May 05 07:28:46 2017] [error] [client xx.xx.xx.xx] FastCGI: incomplete headers (0 bytes) received from server "/dev/shm/cadexdev-php.fcgi", referer: http://www.cadex-dev.ca/shop/admin/entries/multiUse/new`
  
  I don't know if this is host-related. I do have a ticket open with Nexcess but am not certain if this is something specific to Craft instead?
  
  **EDIT:**
  Also, a curious behaviour around this issue. If I save an entry and only wait, say, 20 seconds, quit my browser and then re-open and go to the entries page, the entry is there with the saved changes. No 5+ minute wait.
  
  **Tags:** php
  
  > **Comments:**
  > **username_0**: Just a comment for now... This was all in devmode. I took the site out of dev mode and no issues on any verison of PHP. Can anyone comment on this? Could it only be devmode and the time to write out alot of debug stuff in the Craft logs? I have worked in devmode a fair bit and never recall such slowdowns.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-05-08. Score: 2 | Accepted answer
  
  Had this happen. I believe the cause is twofold:
  
  ## FastCGI's `-idle-timeout` is set too low.
  
  Craft is still writing to the log but Apache cuts it off since it hasn't sent the actual data yet. That's what the `incomplete headers` means.
  
  You'll might find a line like this in your config:
  
  ```
  FastCgiServer /dev/shm/cadexdev-php.fcgi -idle-timeout 10
  
  ```
  
  Some hosts might set it low, like 10 seconds. That could be fine for production to make sure scripts don't take a super long time, but as you've discovered `devMode` could take a little longer to run, depending on the case.
  
  ## RunTasksAutomatically
  
  The other piece is Craft does things in the background. Craft's documentation on [`runTasksAutomatically`](https://craftcms.com/docs/config-settings#runTasksAutomatically) says:
  
  > This setting should be disabled for servers running Win32, or with Apache’s mod\_deflate/mod\_gzip installed, where PHP’s flush() method won’t work.
  
  Some of those tasks clear caches and stuff. If they don't run, you'll get weird intermittent performance issues. Turn it off and run a `cron` job on your server periodically. We run php-fpm on both Apache and nginx and FWIW, we don't have this issue on nginx.
  
  ## Increase PHP's memory
  
  You'll also get a 500 / incomplete headers error if PHP dies because of lack of memory.
  
  > **Comments:**
  > **username_0**: Thanks - very helpful! The idle-timeout makes sense especially since it was clearly writing a lot to the logs in decMode.  
  
  ---
  
  ### Answer by username_0 on 2017-05-05. Score: 1
  
  Well, it seems this was related to devMode. I have had no further issues with it off.
  
  
  ---
  
  