Battle-ready Nginx – an optimization guide
blog.zachorr.com
Battle-ready Nginx – an optimization guide
1–10 of 46 posts
Re: Battle-ready Nginx – an optimization guide
#2What 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 connections doesn't limit nginx anyhow. Nginx closes keepalive connections when it reaches connection limit.
"gzip_comp_level sets the compression level on our data. These levesls can be anywhere from 1-9, 9 being the slowest but most compressed. We’ll set it to 6, which is a good middle ground."
No, it's not "middle ground". It kill performance of your server. With 6 you will get 5-10% better compression, but twice slowness.
"use epoll;"
What's the purpose of this? The docs says: "There is normally no need to specify it explicitly, because nginx will by default use the most efficient method."
"multi_accept tells nginx to accept as many connections as possible after getting a notification about a new connection. If worker_connections is set too low, you may end up flooding your worker connections. "
No, you have completely misunderstood this directive. It isn't related to worker_connections at all.
Re: Battle-ready Nginx – an optimization guide
#3I would love to see some before and after in the wild stats using this configuration. Whilst it would be an apples versus oranges comparison, it would at least show that this config works compared to the default. Maybe a Blitz.io rush test?
Re: Battle-ready Nginx – an optimization guide
#4What 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…
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. And btw, have you ever heard about NAT?
"Most browsers will open up 2 connections" 15 years ago this was true.
Re: Battle-ready Nginx – an optimization guide
#5I'd like to add that using [gzip_static][1] might also be a good idea since nginx doesn't have to gzip your files over and over again and you can gzip the files yourself with the highest compression possible (reducing file size).
[1]: http://nginx.org/en/docs/http/ngx_http_gzip_static_module.ht...
Re: Battle-ready Nginx – an optimization guide
#6What 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…
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"
"and our value is 10,"
Both comments are similar in that there's no explanation why.
The correct value for limit_conn needs to be a balance between whatever your page designer or testing addons measured under normal operation, vs DOS/DDOS harm reduction (not prevention, just... reduction) where setting it to 100000 is probably a bad idea unless you're intentionally doing something really bizarre.
I liked the article for what it is, "explain which settings in nginx can be fine tuned in order to optimize performance for handling a large number of clients". It does a really poor job of explaining how to close the loop by benchmarking and monitoring followed by methodically determining which setting to fine tune and doesn't say much about config file version management either, but that's OK, it self described as a shopping list of performance oriented config options, and at that specific sub-task it delivered successfully. One minor area of improvement would have been to bracket the story with what comes before and after in the process... so your monitoring systems and operations procedures indicates xyz which implies you should ...
Re: Battle-ready Nginx – an optimization guide
#7For 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.
Re: Battle-ready Nginx – an optimization guide
#8What 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.
Re: Battle-ready Nginx – an optimization guide
#9For 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.
Link to nginx.conf: https://github.com/h5bp/server-configs-nginx/blob/master/ngi...
Re: Battle-ready Nginx – an optimization guide
#10Good 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 how they handle a million connections on a single server.