At the top level the configuration file lives in the main context, and from there directives branch into several nested blocks. The most important ones are http {} for HTTP-wide settings, server {} for virtual hosts, location {} for URI-specific behaviour, upstream {} for backend pools, and events {} for connection-level tuning. The http and server blocks both accept performance-related directives that you will tune on any serious deployment.
Two directives define the scale of the worker pool. worker_processes auto; instructs nginx to spawn one worker per detected CPU core, which is the conventional starting point. Inside the events {} block, worker_connections sets the maximum number of simultaneous sockets each worker can keep open; a practical default is 1024, while high-traffic servers often push it to 4096 or 8192. The rough maximum number of concurrent clients the whole server can serve is approximately worker_processes × worker_connections, divided further by two when accounting for the fact that proxied connections consume one socket on the client side and one on the upstream side.
For static file delivery, sendfile on; enables the kernel's sendfile(2) zero-copy path, letting nginx push a file's contents from the page cache straight to the socket without copying through user space. Pair it with tcp_nopush on;, which sets TCP_CORK so response headers and the start of the body are coalesced into a single packet. tcp_nodelay on; does the opposite for keep-alive responses — it clears TCP_NODELAY so small packets go out immediately once the response is finished. Together, tcp_nopush on; for the first packet and tcp_nodelay on; for subsequent keep-alive traffic form the well-known "TCP_CORK / TCP_NODELAY trick" that maximises throughput without hurting latency on follow-up requests.