1

As I understand it, php-fpm makes PHP pages respond faster by managing a farm of pre-loaded PHP interpreter processes so the end user doesn't experience the overhead of initialising the PHP subsystem, but once a PHP page starts executing it takes just as long as it would under "regular" CGI. It's a bit like running a Perl script under mod_perl - the interpreter doesn't run any faster because its bound into the web server executable, it just start up faster.

Am I right, or is there something subtle going on under the hood that makes it run faster overall? The reason for asking is that I have a PHP application that I want to run periodically (I run a 'wget' for its URL every X seconds). I'm not bothered about the response time because its periodic, but I am bothered about the execution time.

kbro
  • 260
  • 1
  • 2
  • 12
  • This question might be more appropriate in ServerFault as its about optimisation rather than programming. I've flagged it to the moderator for a judgment. In the meantime, please answer if you know! –  Feb 20 '15 at 14:09
  • 1
    Sounds like it doesnt matter so much in your case – prodigitalson Feb 20 '15 at 14:17

1 Answers1

2

No, you PHP code itself will not run faster, it's still the same interpreter. You might have a small latency profit compared to normal CGI, but who runs normal CGI anyway? ;-)

Another small help could be the code caching, but that's only really useful if the script is run often.

Tim Stoop
  • 588
  • 5
  • 20
  • 1
    Code cacheing might be a help here. The PHP page is invoked very frequently - once every 5 to 15 seconds - so being able to "copy" the page execution image in some way would be beneficial. With mod_perl, for example, I know I can pre-load libraries before the fork, so if I could do a similar trick with PHP then I'd avoid the overhead of multiple interpreter read-in phases. Is this possible? – kbro Feb 20 '15 at 17:23
  • 1
    I found this - http://thephp.cc/news/2013/06/php-5-5-out-of-the-box-bytecode-cache - which seems to be talking about this - http://php.net/manual/en/book.opcache.php - is this what you're referring to? – kbro Feb 20 '15 at 17:31
  • 1
    Indeed. So if you're using 5.5, that benefit is gone. The problem with APC and 5.4- was that each new process would have it's own cache, it would not shared compiled code between those. That's one thing you can solve with php-fpm. – Tim Stoop Feb 20 '15 at 17:43
  • 1
    I don't understand your comment about the benefit "going" with 5.5. The article says "OpCache is built by default but disabled by default" so I don't get the benefit immediately out-of-the-box - I have to tweak the config file first. And I'm pleased it's "built by default" as it means I shouldn't have to mess around building from source on my Ubuntu server - it should be there in the deb file already. – kbro Feb 20 '15 at 18:12
  • 1
    Ah true that. Haven't used 5.5 myself yet, didn't know it was disabled by default. – Tim Stoop Feb 20 '15 at 18:30