Let’s take the pragmatic approach.

All these limits are things that were hardcoded and designed in the past century when hardware was slow and expensive. We’re in 2016 now, an average wall-mart toaster can process more requests than the default values.

The default settings are actually dangerous. Having hundreds of users on a website is nothing impressive.

worker_process

A related setting, let’s explain it while we’re on the topic.

nginx as load balancer:

• 1 worker for HTTP load balancing.
• 1 worker per core for HTTPS load balancing.

nginx as webservers:

This one is tricky.

Some applications/frameworks/middleware (e.g. php-fpm) are run outside of nginx. In that case, 1 nginx worker is enough because it’s usually the external application that is doing the heavy processing and eating the resources.

Also, some applications/frameworks/middleware can only process one request at a time and it is backfiring to overload them.

Generally speaking, 1 worker is always a safe bet.

Otherwise, you may put one worker per core if you know what you’re doing. I’d consider that route to be an optimization and advise proper benchmarking and testing.

worker_connections

The total amount of connections is worker_process * worker_connections. Half in load balancer mode.

Now we’re reaching the toaster part. There are many seriously underrated system limits:

• ulimits is 1k max open files per process on linux (1k soft, 4k hard on some distro)
• systemd limits is about the same as ulimits.
• nginx default is 512 connections per worker.
• There might be more: SELinux, sysctl, supervisord (each distro+version is slightly different)

1k worker_connections

The safe default is to put 1k everywhere.

It’s high enough to be more than most internal and unknown sites will ever encounter. It’s low enough to not hit any other system limits.

10k worker_connections

It’s very common to have thousands of clients, especially for a public website. I stopped counting the amount of websites I’ve seen went down because of the low defaults.

The minimum acceptable for production is 10k. Related system limits must be increased to allow it.

There is no such thing as a too-high limit (a limit simply has no effect if there are no users). However a too-low limit is a very real thing that results in rejected users and a dead site.

More than 10k

10k is nice and easy.

We could set an arbitrary 1000kk limits (it’s only a limit after all) but that doesn’t make much practical sense, we never get that traffic and couldn’t take it anyway.

Let’s stick to 10k as a reasonable setting. The services which are going for (and can really do) more will require special tuning and benchmarking.

Special Scenario: Advanced Usage

Sometimes, we know that the server doesn’t have much resources and we expect spikes that we can’t do much about. We’d rather refuse users than try. In that case, put a reasonable connection limit and configure nice error messages and handling.

Sometimes, the backend servers are working good and well but only up to some load, anything more and everything goes south quickly. We’d rather slow down than have the servers crash. In that case, configure queuing with strict limits, let nginx buffer all the heat while requests are being drained at a capped pace.