fastcgi in php

Question

PHP

Actually, the presence of a subject in the form in which it is implemented in C is of interest. The current implementation included in the default assembly seems so neutered that there is absolutely no point in using it in my opinion. Or I'm wrong?

Also, in parallel, I would like to finally clarify for myself whether there is any performance advantage for fastcgi compared to mod_php in Apache, because Long googling did not lead to anything concrete.

Thank you.

Answer 1

Until now, disputes on this issue have not subsided. There is no unequivocal opinion, it all depends on the task, and on how your code is optimized to work in fastCGI mode. Here are the materials that will help you understand the topic:
- Dmitry Koterov's article about php fast-cgi
- A variant from the creator of phpDaemona
- An article on setting up php5-fpm
- An article by Ilya Kantor on crossing Symfony and Fast-Cgi
Regarding tests and comparison:
- php -fpm VS apache2+mod_php
- Apache + mod_php compared to Nginx + php-fpm
- Comparing Nginx+PHP-FPM to Apache-mod_php
- PHP Battle: Apache vs PHP-FPM
Some considerations:
The whole PHP-FCGI technology is based on anything but fast cgi for languages ​​like Perl & C with their own scripting interfaces.
If you equalize the conditions of apache and php-fpm, php-fpm wins only in memory, it is due to two additional apache processes. The rest of the winnings are rather dubious.
If you remove the processing of statics and everything superfluous from Apache (for example, using nginx), it processes scripts quite quickly.
On the other hand, in PHP-FPM, the scheme of chrooting and running from under separate users is quite beautifully implemented, which increases security. But he loses in IPC, because does not yet know how to change the number of workers in proportion to the load. If you put too many workers, there will be an overhead of CPU and memory (for which they sin on Apache), if you put too few, there will be denials of service. Well, by the way, whoever is reasonable to manually monitor the FPM processes, they do it.

Answer 2

Well it can work from different users.
It can be screwed to nginx and apache can be removed.
Are you talking about php-fmp?
Out of the box in php, in my opinion, there is no fastcgi.
And I did not understand at all what his castration is?

Answer 3

There is no real FastCGI in PHP by default. In fact, the scripts are re-initialized on every request. Some kind of opcacher can help here, but this has nothing to do with the topic of the question.
There is a phpdaemon project that can act as a FastCGI server. On Habré, they often write about him. Here, for example, is an attempt to translate a symphony project into habrahabr.ru/blogs/php/103875/.
With all due respect to phpdaemon (no sarcasm), I would be afraid to release this into production.
1. How many people are behind this project? How bug-free is the code? Will the author get tired of doing this project tomorrow? The mailing list doesn't look too active...
2. If you already have the code ready, there's a good chance you'll have to finish it.
Etc. My IMHO is that PHP has been ill-suited for this kind of use for years. Yes, it's gotten better, but it's still going to be a long time before the entire PHP infrastructure is ready for true FastCGI applications.
my opinion - if you want real FastCGI, then PHP is not the best choice yet.

Answer 4

There is also this thing: github.com/indeyets/appserver-in-php , WSGI implementation in PHP.

Answer 5

I am using php fast cgi on our project. but the truth is only specific to a certain part of the application.
we had to connect a highly loaded part of the application (link tracking) with IBM MQ Web Sphere and with MySQL
. I had to finish the code on p. but in the end we got the following:
Each apache server raises (depending on the load) from 5 to 100 forks of the application and each fork keeps constant connections to MQ or MySQL. That gave an increase in speed and solved the problem with the number of open connections.
Switching completely to fast-cgi did not work. Some components did not want to work under the fast-cgi part, so they had to be broken into parts.