Challenge 2: A worker_connections Number the OS Won't Support — Solution Walkthrough

What will actually happen:

Setting worker_connections to 100000 does not raise the server's real
capacity, because the OS's own file-descriptor limit for each worker
process is only 1024. Per this chapter's own warning box, each open
connection consumes one real file descriptor — once a worker process
hits its OS-imposed limit of 1024 open file descriptors, it cannot
open any more connections at all, regardless of what worker_connections
says it should be able to handle. Additional connection attempts
beyond that real ceiling will simply fail, or Nginx may log
file-descriptor-related errors, rather than the server successfully
handling 100000 simultaneous connections per worker.

Why the team's expectation is wrong:

The team is treating worker_connections as if it were the only number
that matters, when it's actually just an upper bound Nginx itself will
respect — the OS-level file-descriptor limit is a separate, harder
ceiling that Nginx cannot exceed no matter what its own config says.

What would actually need to happen:

To meaningfully raise capacity here, the team would need to also raise
the OS's own file-descriptor limit (via worker_rlimit_nofile in Nginx
and the corresponding OS-level ulimit setting) to something
comparable to the new worker_connections value — and even then, the
server's actual hardware (RAM, network bandwidth) would need to
genuinely support that many real simultaneous connections.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies this chapter's own warning box to a concrete,
realistic misconfiguration — correctly identifying that the OS file-
descriptor limit is what actually determines the outcome here, not
the number written into nginx.conf.