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?

  • 3
    Most of those are things to do in response to a specific performance problem. Just throwing them all in at once is what developers call "premature optmization." As for the max children, yes, you could increase that if you needed to and you have the spare RAM. – Michael Hampton Apr 2 '15 at 15:30

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.

  • OPCache should always be used fwiw, it's typically not "a little extra performance boost" it's normally a (finger in the air) 30%-ish boost in php performance. +1 for general advice. – AD7six Apr 2 '15 at 17:16
  • I don't have any real performance problem, I just for example think that it's good to set max request for php-fpm thread because of memory leaks which sometimes occur... and I want to prevent such problems with some "premature optimization" before I switch to this server. – Tomas Kudelka Apr 2 '15 at 17:56
  • nginx pastebin.com/g5skBTj6 php-fpm pastebin.com/WjF3Lqi3 opcache pastebin.com/3Mh0thSe – Tomas Kudelka Apr 2 '15 at 18:03
  • +1 for a tactfully worded reply. – Jeff Widman Jun 3 '15 at 1:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.