Nginx – (bad) nginx + php-fpm optimization (done by our provider) review

nginxphp-fpm

I asked our hosting provider for nginx + php-fpm optimization on our managed server. I got this answer:

Hi, There isn't much optimisation that can be done within Nginx as it
is threaded and doesn't use many resources. I have checked that your
php configuration and found that the memory limit is 128M and the
pm.max_children in 50. This means that PHP could use up to 6.5G of
memory on your 2G server. I have reduced the max_children to 15 so
that the server cannot run out memory. Would you like me to do this on
your other server?

First I think there is quite a lot of possible optimisations in nginx, for example I've read this article http://www.softwareprojects.com/resources/programming/t-optimizing-nginx-and-php-fpm-for-high-traffic-sites-2081.html and check if at least some of these optimisations are applied and basically none of them are.

Also I think there is a lot of possible php-fpm optimisations (for example in this article http://www.if-not-true-then-false.com/2011/nginx-and-php-fpm-configuration-and-optimizing-tips-and-tricks/). Again, basically none of them are applied.

Are optimizations mentioned in the articles above useful?

In the end, I think that their logic that I can use maximally 15 children because of 2gb RAM and 128mb memory_limit is a total nonsense, because normally one php-fpm thread takes (according to htop) about 30mb in our application. So imho max number of children should be computed from average usage, am I right? Also, if I have only a single application on the webserver (and the db is on different one and no other service is running on this machine), I can use static number of php-fpm threads, can I?

Best Answer

That person did everything right, I don't see why you say it's "bad". Your performance problem most likely lives in your code and the sysadmin can't fix crappy code. You need to profile your code and see where the bottlenecks are. Once that's done and the issues are fixed you can enable OPCache for a little extra performance boost.

About the articles you linked (the second link is broken by the way), the only really relevant thing would be to use UNIX sockets instead of TCP to talk to PHP-FPM; everything else won't really affect PHP response times (I'm not saying it won't affect overall response times of your server, but enabling GZip won't magically make your app's database queries respond faster).

What the sysadmin told you isn't nonsense. The app may only use 30 MB according to your measurements, but given that the PHP memory limit is set to 128MB means there's nothing that prevents it from using more than 30MB, and once that happens your server starts swapping and/or runs out of memory and it's disaster recovery time because the users are screaming they can't connect to your app.

Also, please post the nginx.conf and php-fpm.conf and I'll update my answer with some new info.