Answers.Body: <p>Have you tried running mod_php as opposed to fastcgi mode?</p>
  
  <p>In the past when we've had this with our servers our first point of call is to determine which part of the stack is limited to 1 core. Our experience has been that its normally mysql. Could you load up mysql with a few concurrent large DB operations and see if it uses multiple cores? This should then good you a direction to head in i.e. which part of the LAMP stack is being limited.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-15T14:21:29.157Z
Answers.Text: Centos builds mod_php into PHP 5.3.3 as is evidenced by 'yum provides mod_php' with a return of 'Repo: base'.  httpd.conf does not even have php in the config file, so I must assume that it is active by default.  Additionally, the php.conf file in the conf.d dir is active.  Did I miss activating mod_php somehow?
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-15T14:23:12.433Z
Answers.Text: Oh, and fastcgi was added as an attempt to figure out what was going on and is now removed with no change in behavior between it being active and being removed.
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-15T14:29:19.543Z
Answers.Text: Sorry, realized that I made it look like I'm not using yum provides correctly.  The package is php-5.3.3-38.el6.x86_64 inside Repo: base and is also listed in Repo: installed.
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-18T09:31:19.077Z
Answers.Text: if you have access to the database then try checking the civicrm_mailing_trackable_url table to see exactly where the URL's are going. This should identify if they're incorrect. You'll need to know the mailing id of the job you've run but you should be able to get that easily enough from the URL of the mailing reports.
Answers.UserDisplayName: Parvez Saleh
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-18T13:55:44.953Z
Answers.Text: Um ... This comment looks like it was intended for a different question.  Hope you can easily find the correct question for this one.
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-18T16:47:50.883Z
Answers.Text: Yep - that was me. I think opening up multiple windows and responding doesn't yield the expected result!
Answers.UserDisplayName: Parvez Saleh
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-14T22:35:34.967Z
Answers.LastActivityDate: 2015-05-17T15:20:25.060Z
Answers.LastEditDate: 2015-05-17T15:20:25.060Z
Answers.UserDisplayName: Parvez Saleh
Body: <p>Keep banging my head against this and can't seem to get anywhere.  I've got a dev site up on Centos 6.6 using KVM, with 4 cores and 8 GB of RAM allocated and PHP 5.3.3.  I'm testing a large import via the web interface import.  When I do, I've noticed that the box never uses more than 25% CPU and only has one thread for Apache.  That 25% CPU usage all sits on one CPU core, effectively maxing it out.  The worrisome thing is, I also can't open another instance of WordPress while this is running.  That means that one user could lock out the whole box with a large report or mass deletion!  (BTW, same thing happens on mass deletion of the 35,000 records, so it's not just the web import script.)</p>
  
  <p>BTW:  The host server isn't that busy and is nowhere near maxed out.  Also, other tasks show that there is no bottle-necks in the usual places like CPU, network, or disk usage.</p>
  
  <p>Things I've tried:</p>
  
  <ul>
  <li>Upping php.ini memory_limit - No changes</li>
  <li>Changing a thousand parameters in MySQL, mainly memory - No changes</li>
  <li>Upping max children in php.ini - No changes</li>
  <li>Adding FastCGI+PHP-FPM - No changes</li>
  <li>Adding WP-Super Cache - No changes</li>
  <li>Adding Memcached - No changes</li>
  <li>Upping file descriptors - No changes</li>
  <li>Adding Max Memory line to wp-config - No changes
  Who knows what else I've forgotten I've tried</li>
  </ul>
  
  <p>Anybody have any ideas here?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-15T16:16:57.173Z
Comments.Text: Still learning the system.  Thanks for the excellent job on the readability cleanup.
Comments.UserDisplayName: G H
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-05-20T15:09:29.440Z
Comments.Text: Just to add a little more info. Opening another browser allows the system to respond while a major deletion/addition is ongoing. So Firefox won't respond in a second tab while this is going on, but another browser on the same machine will pull pages quickly, so that's good news.
Comments.UserDisplayName: G H
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-12-18T20:36:08.637Z
Comments.Text: Apparently WordPress has also added a couple of new "features" to the wp-config.php file for PHP memory management.  For more information on this see:  https://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP  It defaults to a max of 40 MB for single site install or 64 MB for multi-site installs.  (Still experiencing a lot of the same issues though.
Comments.UserDisplayName: G H
Tags: <wordpress><best-practice><debugging>
Title: CiviCRM Wordpress Optimization
ThreadText: # CiviCRM Wordpress Optimization
  
  (Asked by: username_0 on 2015-05-14)
  
  Keep banging my head against this and can't seem to get anywhere. I've got a dev site up on Centos 6.6 using KVM, with 4 cores and 8 GB of RAM allocated and PHP 5.3.3. I'm testing a large import via the web interface import. When I do, I've noticed that the box never uses more than 25% CPU and only has one thread for Apache. That 25% CPU usage all sits on one CPU core, effectively maxing it out. The worrisome thing is, I also can't open another instance of WordPress while this is running. That means that one user could lock out the whole box with a large report or mass deletion! (BTW, same thing happens on mass deletion of the 35,000 records, so it's not just the web import script.)
  
  BTW: The host server isn't that busy and is nowhere near maxed out. Also, other tasks show that there is no bottle-necks in the usual places like CPU, network, or disk usage.
  
  Things I've tried:
  
  * Upping php.ini memory\_limit - No changes
  * Changing a thousand parameters in MySQL, mainly memory - No changes
  * Upping max children in php.ini - No changes
  * Adding FastCGI+PHP-FPM - No changes
  * Adding WP-Super Cache - No changes
  * Adding Memcached - No changes
  * Upping file descriptors - No changes
  * Adding Max Memory line to wp-config - No changes
    Who knows what else I've forgotten I've tried
  
  Anybody have any ideas here?
  
  **Tags:** wordpress, best-practice, debugging
  
  > **Comments:**
  > **username_0**: Still learning the system.  Thanks for the excellent job on the readability cleanup.  
  > **username_0**: Just to add a little more info. Opening another browser allows the system to respond while a major deletion/addition is ongoing. So Firefox won't respond in a second tab while this is going on, but another browser on the same machine will pull pages quickly, so that's good news.  
  > **username_0**: Apparently WordPress has also added a couple of new "features" to the wp-config.php file for PHP memory management.  For more information on this see:  https://codex.wordpress.org/Editing_wp-config.php#Increasing_memory_allocated_to_PHP  It defaults to a max of 40 MB for single site install or 64 MB for multi-site installs.  (Still experiencing a lot of the same issues though.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-05-14. Score: 3
  
  Have you tried running mod\_php as opposed to fastcgi mode?
  
  In the past when we've had this with our servers our first point of call is to determine which part of the stack is limited to 1 core. Our experience has been that its normally mysql. Could you load up mysql with a few concurrent large DB operations and see if it uses multiple cores? This should then good you a direction to head in i.e. which part of the LAMP stack is being limited.
  
  > **Comments:**
  > **username_0**: Centos builds mod_php into PHP 5.3.3 as is evidenced by 'yum provides mod_php' with a return of 'Repo: base'.  httpd.conf does not even have php in the config file, so I must assume that it is active by default.  Additionally, the php.conf file in the conf.d dir is active.  Did I miss activating mod_php somehow?  
  > **username_0**: Oh, and fastcgi was added as an attempt to figure out what was going on and is now removed with no change in behavior between it being active and being removed.  
  > **username_0**: Sorry, realized that I made it look like I'm not using yum provides correctly.  The package is php-5.3.3-38.el6.x86_64 inside Repo: base and is also listed in Repo: installed.  
  > **username_1**: if you have access to the database then try checking the civicrm_mailing_trackable_url table to see exactly where the URL's are going. This should identify if they're incorrect. You'll need to know the mailing id of the job you've run but you should be able to get that easily enough from the URL of the mailing reports.  
  > **username_0**: Um ... This comment looks like it was intended for a different question.  Hope you can easily find the correct question for this one.  
  > **username_1**: Yep - that was me. I think opening up multiple windows and responding doesn't yield the expected result!  
  
  ---
  
  