Rejection of apache in a bunch of nginx + httpd + php?

Question

PHP

What is the right way to connect php to nginx now? What is the current method? PHP 5.3.17.
Are there any downsides to deprecating httpd (rewrite is not used)?

Answer 1

php-fpm

Answer 2

I'm afraid that I'll take a bunch of minuses for my advice, but nevertheless:
Three months ago, I devoted 2 weeks to tests - which is better. True - I had PHP 5.4, nginx 1.2 and all this on Debian
Tested (and, of course, tuned the OS and all other settings during the tests) four options - nginx+PHP, nginx+ahache+PHP, nginx+nginx+PHP ( in the latter case, there is an external nginx that works with static and sends requests to PHP to the internal nginx) and nginx+apache+PHP-FPM.
Internal nginx and apache run in keepAlive off mode
Apache cut off everything superfluous (in my case, dir, auth, mime, rpaf are left). ,haccess is not used (if something needs to be restricted, we set it directly in the site configs, all redirects are through external nginx)
External nginx has gzip enabled, caching disabled
Internal servers log only php errors
In all cases, siege was set against real sites with an increased timeout and 1000 concurrent requests.
Yes - and the machine - Hetzner's with 24 GB of memory.
The results are as follows:
nginx + php - not quoted at all. displays memory in swap, load in top - 140 - 150 about a minute after the start of the siege. Manipulations with the system and settings did not help.
nginx + apache + php-fpm - eats memory and gets into the swap, the processor does not load much. There are problems with stability (siege worked stably with the parameter no more than -c 500)
nginx + apache + php and nginx + nginx + php - approximately the same results - the average load in the top is 3, the average memory consumption is 14 - 16 Gb. The number of transactions is also about the same (apache showed results about 3-4 transactions per second better)
nginx + nginx + php worked a little less stable than nginx + apache + php (not a little, even a little - that is, a couple of three times the socket still fell, but in the case of apache this was not the case)
I had to stop at the classics (although I really wanted to limit myself to nginx)
However - this is all - lyrics. I would recommend doing a series of tests with your software (and with your admin) - you might get different results. However - and this is almost certain - the option with a reverse proxy will obviously be more productive .

Answer 3

There are no special minuses (Apache is a very functional "enterprise" reactor, it is redundant for most projects).
see php.net/manual/ru/install.fpm.php
In order to write nginx configs normally without crutches, you need to work a little with it. (translating production earlier than the test / dev site is definitely not worth it).
Everyday evidence: if the problems are not in Apache, but in the head ^ W crooked code, no change in the web server will solve them.

Answer 4

NGINX + PHP-FPM has been working very stable for me for more than 2 years, I used to connect to a port, for example: :9000, now it’s more convenient to connect via sockets