php-fpm, the improved process manager for php-cgi, is now included in [an experimental branch of] the PHP 5.3.2 distribution. There are some deb packages out there and it has become very easy to install. No compiling necessary. I recently installed it on my home dev server to test it out and it worked without too much trouble. My home server is running ubuntu 9.10, the karmic release.
The lucid release of ubuntu is due to be released in about six weeks, April 29, 2010. The 10.04 lucid release is one of the LTS releases that ubuntu does every two years which carries a longer support term. As of today, lucid has the 5.3.1 version of PHP that does not include php-fpm but [dotdeb] has a 5.3.2 package [with fpm].
Drupal core and many modules have been updated for compatibility with the 5.3 series over the last year but some modules are still not there yet. Among the modules I use regularly, google analytics was the only one that threw an error into watchdog. I found a one line patch diff in the issue queue that addressed the issue. Many major distributions are moving to the 5.3 branch so module compatibility with 5.3 should continue to improve without regard to php-fpm.
Since a php dev boasted a 20% speed increase with Drupal using 5.3 and because nginx users are especially interested in php-fpm, I thought I'd start a discussion.
Has anyone else tested 5.3.2 with php-fpm or used it in production?
Comments
Great news indeed
I haven't tested 5.3.2. yet, but I found that switching from 5.2.x to 5.3.x alone made sites feel faster. Although, like you said, some modules, e.i. 'date', aren't completely compatible yet.
After skimming the changelog for PHP 5.3.2 at http://www.php.net/ChangeLog-5.php#5.3.2 I couldn't find any mention of the inclusion of php-fpm, but I take your word for it. The fix for http://bugs.php.net/50351 and the integration of fpm are very compelling reasons for updating. On paper, performance should be a lot better.
Can anyone confirm this ?
You're right. Not included
You're right. Not included in the official 5.3.2. It's still an experimental branch:
http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM
The dotdeb guys included the php-fpm sapi themselves:
http://www.dotdeb.org/2010/03/08/php-5-3-2-is-available-too/
Thanks for the catch.
FPM is in the php5.3 main
FPM is in the php5.3 main branch. not in the .tar.gz release
happy compiling!
--
Mike Nichols
My Own Soho, LLC
mike@myownsoho.net
www.myownsoho.com
Yeah. They moved it into the
Yeah. They moved it into the main branch and it is in the 5.3.3RC2 tarball, so it should be in the 5.3.3 release which should be soon.
This is a link with
This is a link with instructions on installing a couple extra packages to overcome some debian/ubuntu naming and version incompatibilities:
http://swik.net/PHP/Planet+PHP/Installing+PHP+5.3.1+On+Ubuntu+9.10+%28Ka...
I also install php5-mcrypt since phpmyadmin likes it, but the version in the dotdeb repo requires libltdl3 instead of the libltdl7 that ubuntu has, so I installed the libltdl3 package from hardy:
http://mirrors.kernel.org/ubuntu/pool/main/libt/libtool/libltdl3_1.5.26-...
And I set the default timezone in /etc/php5/fpm/php.ini (and /etc/php5/cgi/php.ini for drush) to solve a date error as recommended in
http://drupal.org/node/325827#comment-2704770
And here's the patch for
And here's the patch for google analytics
http://drupal.org/node/679404#comment-2668756
also courtesy of http://drup.org/drupal-and-php-53 are some other patches:
imageapi http://drupal.org/node/540486
calendar http://drupal.org/node/613528
date http://drupal.org/node/549884
rules http://drupal.org/node/703294
admin_menu http://drupal.org/node/615058
views http://drupal.org/node/452384
cool, thanks for the links to
cool, thanks for the links to those patches.
I guess, I'll have something to try out over the course of the weekend ;)
Another 5.3 patch to fix an
Another 5.3 patch to fix an error that happens when using the core search.
http://drupal.org/node/587568
Issue for Diff module with
Issue for Diff module with patch:
http://drupal.org/node/639320
That patch looks like it's against an alpha release.
I installed the dotdeb
I installed the dotdeb packages on my personal public VPS running karmic which has private stuff and nothing mission-critical and it's working very well.
So I was wondering to myself how many child processes I should set and it turns out that I don't get more performance with more than 4 child processes, which is the number of "virtual" xen CPUs that I have. This is all run from the local machine with all caching off at my test site http://test.brianmercer.com
If I run ab with 1 concurrency I get about 5.5 requests per second. test1 If I run 2 concurrency I get about 11 r/s. test2 If I run 3 I get about 16 (test3) and if I run 4 I get about 20ish r/s. test4 All with pretty reasonable 200-350ms response times with the modules I have installed. If I go over 4 concurrency, the response times get longer but the requests per second stay the same. At 20 concurrency the r/s is still 21ish but the response time is getting up around 1300ms mean test5 and at 40 concurrency the r/s is 21ish but the response time is up to a mean of 2800ms. test6
But if I increase the child processes from 4 to 8, the r/s and response rates stay about the same. Which I suppose makes sense since the whole point is that I'm going to be CPU bound, but I'm wondering why I never realized this when I was setting up the number of children while using php-cgi. And does this only apply to virtual xen CPU slices which aren't actually real CPU cores? From htop I can see all the 8 child processes getting CPU time and the 4 "CPU's" maxing out but the end results are the same, only more memory use. So it seems I might as well save the memory for OS cache and run 4 children.
The nice thing is that the memory use stays solid during the tests. Watching htop bars while running the tests show the CPU bars maxing out but the memory use staying put, which is what I need for my 360MB VPS. It makes me wonder how I can get more CPU power when/if I need it. Linode offers extra ram and storage on demand but I think you have to go to higher plans to get more CPU and I'm not sure how they can measure that CPU share, except that larger plans with Linode means fewer nodes per machine. So that could mean a larger share of their 8 core machines.
Anyways, I thought I'd share this info about how many children to run. It's nice to see that php is very efficient at using all of the CPU "cores" even if they're only virtual. Other than the annoyance of tracking down contrib module patches for php 5.3, these debianeque dotdeb php-fpm packages have worked out nicely without any compiling.
P.S. For boost cached pages it's about 3600 r/s with 27ms mean response time. test7