PHP 5.3.3 Released | Hacker News Reader

PHP 5.3.3 Released

php.net

49 pointsUncle_Sam31 comments

"Added FastCGI Process Manager (FPM) SAPI."

This looks particularly interesting. I googled it and found http://php-fpm.org/ . I didn't previously realize that a fastcgi implementation had been merged into PHP core. Sweet!

Yes! It's main and biggest news!

Can someone explain this to me?

PHP's two most popular SAPIs are embedded and FastCGI. mod_php is embedded inside of Apache (and is problematic), whereas the FastCGI SAPI communicates via TCP or a Unix socket. The two major (there may be others) FastCGI process managers are spawn-fcgi (a Lighttpd subproject, http://redmine.lighttpd.net/projects/spawn-fcgi/wiki) and PHP-FPM. The latter is quite stable and has some nifty features (http://php-fpm.org/).

PHP-FPM used to exist as a patch for PHP (http://php-fpm.org/downloads/). It's now in core, and can be built with the --enable-fpm configure flag.

A bit off the topic, is there any good introductory doc on how apache modules work?

Yep:

http://amzn.com/0132409674

Thanks.

I wonder if this solves the problem I've had of having a single APC cache across php-cgi children with fastcgi. From what I read handing the process management off to PHP would achieve that, is that what this is doing?

Glad I'm not the only one who cares about this, but don't have more information - only the same question.

Yes (second to last comment):

http://pecl.php.net/bugs/bug.php?id=11988

How have you been managing the php-cgi children?

Oh cool, I have read that post before but must have skipped over it. I tried the hackish method in that last comment before but it gave me problems. At the moment given that it's fairly low load what I was doing I just left the default method in place which doesn't share APC.

What's "problematic" about mod_php? It's got to be one of the more widely used bits of software out there. Like anything, I'm sure there are tradeoffs involved, but perhaps it's better to be a bit more explicit about what they are rather than stopping at "problematic"?

I've had a couple problems but I wouldn't call it problematic:

1) When you select mod_php/the Apache SAPI, certain functions get disabled like chroot() and pcntl_fork() since they're not safe to be used under Apache. This is annoying when you have some backend scripts that need those functions.

2) If you run PHP with all the popular plugins, you're looking at about 15MB per Apache process/thread. @256 active clients that's almost 4GB of RAM. Insane, especially considering it's loaded in memory whether or not the requested resource is PHP or not.

I recently switched to Nginx+FastCGI and I'm very happy with the speed and memory usage. FPM makes it even better.

How much memory does each FCGI process take up, just out of curiosity? You still need 256 of them to deal with that many concurrent connections.

I run bare php FCGI processes that use 4.5MB of memory and use dl() to load the extra libs on demand now.

For 2, wouldn't most of that memory be either COW or physically shared, read-only? It's been about a year and a half since I've operated a large PHP site, but I don't recall the apache workers getting anywhere close to 15MB each, unless a request was operating on a larger than normal dataset. (this site used curl, gd, memcache, uuid, pspell, tidy, soap, and probably some others I've forgotten, loaded dynamically.)

PHP has had a fastcgi implementation for ages, but this adds process management to it.

Great news. This makes it significantly easier to get PHP running on Nginx.

Fortunately, it was never hard.

  Before (5.3.x):
  tar xjvf php-5.3.2.tar.bz2
  cd php-5.3.2
  svn co http://svn.php.net/repository/php/php-src/trunk/sapi/fpm sapi/fpm
  ./buildconf --force
  ./configure --enable-fpm ...
  make
  sudo checkinstall -D make install

  After (5.3.x):
  tar xjvf php-5.3.3.tar.bz2
  cd php-5.3.3
  ./configure --enable-fpm ...
  make
  sudo checkinstall -D make install

  Before (< 5.3.x):
  tar xjvf php-5.2.13.tar.bz2
  wget php-fpm.org/downloads/php-5.2.13-fpm-0.5.14.diff.gz
  gzip -cd php-5.2.13-fpm-0.5.14.diff.gz | patch -d php-5.2.13 -p1
  cd php-5.2.13
  ./configure --enable-fastcgi --enable-fpm ...
  make
  sudo checkinstall -D make install

  After (< 5.3.x):
  PHP 5.2.x is no longer supported. Stop using it.

nginx's configuration is the same for all.

Eh, the main difference to me is that now it is part of the official source, it will likely be included in package manager builds on major Linux distros, instead of having to compile from source at all.

The backwards compatibility break they did got me thinking, it would be great to see a major PHP release that broke backwards compatibility to get things right as Python have done with version 3. I think anyone not interested in porting their code would already have a PHP more than suitable for their needs.

If you could break backwards compatibility, what would you change?

I just mean the little niggling things people complain about like all the functions in the global namespace, inconsistent arguments, inconsistent error handling. I guess though a lot of PHP support comes from the deploy everywhere make minimal changes to old code ideas, so I can see why their quiet happy to not want to break to much old code.

What would be left would be hardly recognizable as PHP.

I dunno... I think it would be essentially the same for new users (since they have to look up things anyway), and it would certainly feel like PHP...

Actually, I agree. I have often thought there is a space for a revamped PHP, with compatible syntax (because people know it) but with many of the niggles removed and a better core library.

Accessible core libraries that are people are encouraged to use, stuff without a mess of dependencies to. You hardly ever seen introductions to PHP that encourage library use, it's mostly about rolling your own stuff.

I don't think that is such a great idea - stuff like == vs ===, PHP's class system and PHP's namespaces is all questionable...

Still waiting for eaccelerator to catch back up.

(their data storage API is removed from their 5.3.x build)

Prefer it's stability over APC and xcache.

Can you describe APC's instability? I've had no problems, and in fact had issues with eAccelerator.

Added FastCGI Process Manager (FPM) SAPI. - good news.

Reply on news.ycombinator.com