Answers.Body: <p>This should no longer be an issue in the next (post <a href="http://buildwithcraft.com/updates#build2641" rel="nofollow">2.3.2461</a>) release of Craft.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-31T18:27:45.013Z
Answers.LastActivityDate: 2015-03-31T18:27:45.013Z
Answers.UserDisplayName: Brad Bell
Answers.Body: <p>The first thing I would try is to "Disable" every single one of your plugins. If that solves the problem, go through and re-"Enable" each one of them until you have pinpointed which plugin is causing the problem.</p>
  
  <p>If that doesn't help at all, the next thing I'd do is to open up the Craft logs, and see if anything suspicious is in there...</p>
  
  <pre><code>/craft/storage/runtime/logs/
  </code></pre>
  
  <p>And if you're still not seeing anything noteworthy, then it might be worth submitting a ticket from the "Get Help" widget on your dashboard. Be sure to include your logs, database export, and files.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-24T17:01:51.910Z
Answers.Text: It's happening across all of our Craft installations on this server, even the ones with no plugins installed. I can't see anything unusual in the logs - no weird errors or notices as far as I can see .
Answers.UserDisplayName: Alex H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-24T17:12:12.610Z
Answers.Text: In that case, I'd submit a bug report to P&T, using the "Get Help" widget. They may need to access your server directly to do some troubleshooting.
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-26T14:43:48.113Z
Answers.Text: Would you mind posting back here when you receive an answer @AlexH? I'd love to see what was said. I have a craft site on Dreamhost that works fine, but when saving an entry it takes an exceptionally long time for some reason. I've only ever seen it on that host.
Answers.UserDisplayName: Peter Tell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-27T14:47:42.897Z
Answers.Text: Hi Peter, Brad at P&T is still investigating this issue - I will update this question with an answer when I can.
Answers.UserDisplayName: Alex H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-31T19:39:13.200Z
Answers.Text: @PeterTell Looks like this was a [bug in Craft](http://craftcms.stackexchange.com/a/8943/45), and fixed in the next release.
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-24T16:53:19.710Z
Answers.LastActivityDate: 2015-03-24T16:53:19.710Z
Answers.UserDisplayName: Lindsey D
Body: <p>We're currently in the process of migrating web server to a new Ubuntu 14.04 box, and we are running into the same problem across our multiple Craft installations which is majorly affecting our workflow across all projects at the moment.</p>
  
  <p>When we're updating content in Craft, we're frequently clicking 'Save' on categories, entries etc then having the server response timeout on us. The browser says 'Waiting for reply...', but it can take up to 5 minutes for the page to refresh with the saved data, which does appear to eventually being saved correctly.</p>
  
  <p>I've spoken to our hosting company, and they told me that they couldn't see anything unusual in the logs, and advised that I install New Relic to be able investigate the problem further.</p>
  
  <p>I installed the monitoring software along with the PHP service, and added a line at the top of index.php in Craft to identify the individual applications in New Relic.</p>
  
  <p>I've just experienced the problem again on this site, when I was saving a new nested Category.</p>
  
  <p>Going into New Relic transactions, I see in the transaction breakdown for the saveCategory transaction that 300,000 ms was spent in CInlineAction::runWithParams.</p>
  
  <p>I've included the summary trace from NewRelic in the attached image.</p>
  
  <p>Could this is a bug inside Craft, or if there is anything specific to our server which maybe causing this?</p>
  
  <p><img src="https://i.sstatic.net/sOu3B.jpg" alt="New Relic trace"></p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-31T19:38:23.247Z
Comments.Text: Per [Brad's answer](http://craftcms.stackexchange.com/a/8943/45), this turned out to be a bug in Craft, which has since been fixed. Closing this thread as a "bug report".
Comments.UserDisplayName: Lindsey D
Tags: <newrelic><timeout>
Title: Saving causes server not to respond
ThreadText: # Saving causes server not to respond
  
  (Asked by: username_0 on 2015-03-24)
  
  We're currently in the process of migrating web server to a new Ubuntu 14.04 box, and we are running into the same problem across our multiple Craft installations which is majorly affecting our workflow across all projects at the moment.
  
  When we're updating content in Craft, we're frequently clicking 'Save' on categories, entries etc then having the server response timeout on us. The browser says 'Waiting for reply...', but it can take up to 5 minutes for the page to refresh with the saved data, which does appear to eventually being saved correctly.
  
  I've spoken to our hosting company, and they told me that they couldn't see anything unusual in the logs, and advised that I install New Relic to be able investigate the problem further.
  
  I installed the monitoring software along with the PHP service, and added a line at the top of index.php in Craft to identify the individual applications in New Relic.
  
  I've just experienced the problem again on this site, when I was saving a new nested Category.
  
  Going into New Relic transactions, I see in the transaction breakdown for the saveCategory transaction that 300,000 ms was spent in CInlineAction::runWithParams.
  
  I've included the summary trace from NewRelic in the attached image.
  
  Could this is a bug inside Craft, or if there is anything specific to our server which maybe causing this?
  
  ![New Relic trace](https://i.sstatic.net/sOu3B.jpg)
  
  **Tags:** newrelic, timeout
  
  > **Comments:**
  > **username_1**: Per [username_2's answer](http://craftcms.stackexchange.com/a/8943/45), this turned out to be a bug in Craft, which has since been fixed. Closing this thread as a "bug report".  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2015-03-31. Score: 2 | Accepted answer
  
  This should no longer be an issue in the next (post [2.3.2461](http://buildwithcraft.com/updates#build2641)) release of Craft.
  
  
  ---
  
  ### Answer by username_1 on 2015-03-24. Score: 2
  
  The first thing I would try is to "Disable" every single one of your plugins. If that solves the problem, go through and re-"Enable" each one of them until you have pinpointed which plugin is causing the problem.
  
  If that doesn't help at all, the next thing I'd do is to open up the Craft logs, and see if anything suspicious is in there...
  
  ```
  /craft/storage/runtime/logs/
  
  ```
  
  And if you're still not seeing anything noteworthy, then it might be worth submitting a ticket from the "Get Help" widget on your dashboard. Be sure to include your logs, database export, and files.
  
  > **Comments:**
  > **username_0**: It's happening across all of our Craft installations on this server, even the ones with no plugins installed. I can't see anything unusual in the logs - no weird errors or notices as far as I can see .  
  > **username_1**: In that case, I'd submit a bug report to P&T, using the "Get Help" widget. They may need to access your server directly to do some troubleshooting.  
  > **username_3**: Would you mind posting back here when you receive an answer @username_0? I'd love to see what was said. I have a craft site on Dreamhost that works fine, but when saving an entry it takes an exceptionally long time for some reason. I've only ever seen it on that host.  
  > **username_0**: Hi username_3, username_2 at P&T is still investigating this issue - I will update this question with an answer when I can.  
  > **username_1**: @username_3 Looks like this was a [bug in Craft](http://craftcms.stackexchange.com/a/8943/45), and fixed in the next release.  
  
  ---
  
  