For anyone who is interested in nginx tuning, please follow the H5BP nginx repo: https://github.com/h5bp/server-configs-nginx , which is very well documented already and still being maintained.
Interesting stuff. Thanks for posting it
Battle-ready Nginx – an optimization guide
31–40 of 46 posts
Re: Battle-ready Nginx – an optimization guide
#32I wish I could find a guide like this for Apache as well. Computing max clients and other options seems like pure guess work and constant failure =/
Re: Battle-ready Nginx – an optimization guide
#33My favorite comment from this whole blog:
"(warning, a neckbeard and an operating systems course might be needed to understand everything)"
Thats actually true with a fair amount of what people fiddle around with. I see a lot of tuning advice based on what I can only assume is guessing. I guess this is as good of a "caveat emptor" as anything.
Re: Battle-ready Nginx – an optimization guide
#34Good introduction to nginx. However, the guide states: "Keep in mind that the maximum number of clients is also limited by the number of socket connections available on your sytem (~64k)". This is incorrect. The system can open ~64k connections per [src ip, dst ip] pair. In the case of a webserver listening on just 1 port, it means you can open 64k connections per remote IP, which is why some people can write about h…
That's true for incoming connections, but if you're proxying back to something else then the limit does apply to the outgoing ones.
Only if you don't use HTTP/1.1 on the proxy side.
proxy_http_version 1.1;
proxy_set_header Connection "";
Re: Battle-ready Nginx – an optimization guide
#35You can also use "sudo service nginx reload" instead of restarting. Helps if it's in use and you don't want to drop any active users.
Re: Battle-ready Nginx – an optimization guide
#36You explain the "what" but not the "why".
Re: Battle-ready Nginx – an optimization guide
#37If you set an application to use more file descriptors than ulimit -n returns, then either the application will be smart and fix its configuration by using MAX(configured limit, ulimit -n) or it'll start dropping requests because it's assuming it's allowed to open more file descriptors.
Increasing an application's maximum file descriptors past ulimit -n is bad advice. The proper way is to increase the limit in /etc/security/limits.conf (note that assigning a limit to * applies it to every user but root, so if you really want to assign a limit to every user, you must assign it to both * and root) and then increase the application's max file descriptors. Restarting the application is usually required, although on newer versions of Linux, changing limits for running processes is possible.
Re: Battle-ready Nginx – an optimization guide
#38Earlier quoted context omitted.
And even more: "send_timeout 2;" Mobile clients from another continent will "thank you" for this setting when they cannot open your site. "error_log /var/log/nginx/error.log crit;" A way to be unaware when something is wrong with your server. Nginx produces not only "crit" errors, but a bunch of very useful warnings, that need attention. "limit_conn addr 10;" Chrome and Firefox usually open more than 10 connections.…
> Chrome and Firefox usually open more than 10 connections. According to browserscope.org both browsers open only 6 connections per hostname.
For http connections that's true. Websockets have a separate pool though, and a much higher cap (200 in Firefox). Nginx recently added websocket support.
Re: Battle-ready Nginx – an optimization guide
#39For anyone who is interested in nginx tuning, please follow the H5BP nginx repo: https://github.com/h5bp/server-configs-nginx , which is very well documented already and still being maintained.
Thank you! Do you know of any equivalent for Apache?
Re: Battle-ready Nginx – an optimization guide
#40What purpose of the article if in the documentation at nginx.org/en/docs/ you can find the same? And, btw, you are giving bad advices. You are wrong here: "By default, nginx sets our keep-alive timeout to 75s (in this config, we drop it down to 10s), which means, without changing the default, we can handle ~14 connections per second. Our config will allow us to handle ~102 users per second." No, the keepalive connect…
Looks like the author of the linked blog post is reading HN. They have modified the article in an attempt to address your criticisms.
.. and that's a good thing, the circle of HN life.