Web Server Concurrency Limits:
Nginx vs. Apache / LiteSpeed

Core Mechanism

Web server concurrency architecture determines the upper bound on simultaneous TCP connections a server can maintain before it begins dropping new client requests or queuing them behind a backlog that exhausts the OS socket buffer. The fundamental dichotomy is between process-per-connection (Apache Prefork) and event-driven multiplexing (Nginx, LiteSpeed, Apache Event MPM). In the process-per-connection model, every active client holds an OS process in memory for the full duration of the connection — including idle keepalive intervals, slow TLS negotiation, and sluggish client upload speeds. This makes RAM consumption a direct linear function of concurrent connection count. In the event-driven model, a single worker process uses the Linux epoll syscall to monitor thousands of socket file descriptors simultaneously, switching between them only when I/O events are ready — never blocking idle on a slow client. The worker’s RAM cost is fixed regardless of how many connections it is multiplexing.

In Nginx, the connection capacity equation is explicit and operator-controlled: total simultaneous connections = worker_processes × worker_connections. The worker_processes directive should be set to auto, which maps one worker per available CPU core. The worker_connections directive — set inside the events block — defines how many connections each worker can hold open concurrently. The default value of 1024 is a conservative legacy setting from an era of lower traffic volumes; modern production servers routinely require 4096–16384, constrained only by the system’s ulimit -n (open file descriptor ceiling) and available RAM for socket buffers. Each open connection consumes one file descriptor on the OS level, making the ulimit the hard system ceiling above which even a correctly configured Nginx will refuse new connections with a “too many open files” error.

Keepalive configuration is the second critical tuning axis and operates in direct tension with connection pool capacity. A keepalive connection holds a TCP socket open after a request completes, allowing the same client to reuse it for subsequent requests without a three-way handshake. This reduces latency for returning visitors but consumes a worker_connections slot for the full keepalive_timeout duration. Under high-traffic spikes, an aggressive keepalive timeout (e.g., 75 seconds) combined with a sustained stream of new visitors means the connection pool fills with idle keepalive sockets, leaving no capacity for new connection accepts. The production tuning target is a keepalive_timeout of 10–15 seconds and a keepalive_requests ceiling of 100–500, which bounds each persistent socket’s lifespan and prevents any single client from monopolising a connection slot indefinitely.

Server Concurrency Architecture Matrix

The following table maps the operative concurrency configuration parameters across Nginx, Apache (Prefork and Event MPM), and LiteSpeed. These are the directives that define the effective connection ceiling on each platform. Understanding their interaction with RAM, file descriptor limits, and PHP-FPM worker counts is prerequisite to setting any of them correctly — each parameter is a constraint in a system of interdependent limits, not an independent dial.

Nginx Concurrency Configuration Reference

The Nginx configuration surface for concurrency control is compact but interdependent. Every directive in the events block and the http keepalive context must be understood as part of a single capacity equation — adjusting one without recalculating its dependents produces unpredictable results under load. The multi_accept on directive, for instance, instructs each worker to accept all queued connections in a single accept() loop iteration rather than one per event cycle, which significantly increases burst absorption capacity at the cost of slightly higher per-spike CPU usage. The use epoll directive explicitly selects Linux’s scalable I/O event notification interface, bypassing the older and less efficient select() and poll() syscalls that Nginx may fall back to on misconfigured builds.

The keepalive_timeout and keepalive_requests directives in the http block govern how long and how many times an idle persistent connection will be tolerated. Setting keepalive_timeout 0 disables keepalive entirely — appropriate only for very high-traffic public endpoints where connection slots are perpetually scarce and client reuse patterns are low-value (e.g., CDN origin pulls, ad traffic ingestion). For WordPress sites with returning authenticated users or WooCommerce checkout flows, a timeout of 10–20 seconds and a request cap of 100–200 is the correct balance: long enough to serve a multi-page session over a single TCP connection, short enough to reclaim the slot before the next traffic burst arrives.

Apache MPM & LiteSpeed Concurrency Tuning

Apache’s concurrency ceiling is controlled by the active Multi-Processing Module (MPM). The Prefork MPM — the default on many cPanel and legacy shared hosting stacks — uses the MaxRequestWorkers directive as its hard connection ceiling. The correct value is not a round number chosen by intuition; it is a calculated result: divide available RAM (total server RAM minus OS + MySQL overhead) by the average Apache process size in megabytes, measured via ps aux --sort=-%mem | grep apache2. A server with 2GB RAM reserved for Apache and an average process size of 20MB yields a maximum of 100 simultaneous connections before OOM risk. Exceeding this number does not improve throughput — it causes memory pressure that degrades performance for all concurrent requests and ultimately triggers the OOM killer.

The Apache Event MPM is the architectural bridge between Prefork’s process model and Nginx’s event loop. It assigns one thread to manage multiple keepalive connections asynchronously, reserving full process/thread weight only for requests that are actively being served. This dramatically reduces RAM consumption for keepalive-heavy workloads and is the recommended MPM configuration for any Apache server that cannot be migrated to Nginx or LiteSpeed. Its key tuning directives are ThreadsPerChild (threads per child process, default 25), MaxRequestWorkers (total thread ceiling), and AsyncRequestWorkerFactor (the multiplier controlling how many idle keepalive connections each thread manages — default 2, safely raisable to 4 on modern hardware). LiteSpeed Web Server (LSWS) uses a native asynchronous event architecture with its own LSAPI PHP handler that bypasses FastCGI overhead entirely, achieving the lowest per-request PHP execution latency of the three platforms. Its concurrency tuning is managed primarily through the LiteSpeed Admin Panel’s Server → Tuning → Max Connections and PHP LSAPI worker count settings, rather than flat configuration files.

Takeaway

The web server concurrency limit is the first gate through which every incoming TCP connection must pass. Misconfiguring it — either by leaving worker_connections at its legacy default of 1024, by failing to set worker_rlimit_nofile high enough to match it, or by allowing keepalive timeouts to hold slots open for 75 seconds during a burst event — means the server begins refusing legitimate clients before CPU or RAM resources are anywhere near exhausted. This is the class of production failure that is most commonly misdiagnosed as a hardware capacity problem, when it is entirely a configuration problem solvable without spending a cent on infrastructure. Profile your active connection count under load with ss -s, cross-reference it against worker_connections × worker_processes, and validate your keepalive slot reclaim rate against your traffic spike duration before concluding that vertical scaling is the answer.

For WooCommerce and ad-traffic-heavy WordPress sites, the critical insight is that the web server connection layer and the PHP-FPM worker layer are a coupled system — tuning one without the other creates a mismatch that manifests as upstream timeout errors in Nginx logs or 502/504 responses under load. The correct tuning sequence is always: calculate PHP-FPM pm.max_children from RAM budget first (NODE 009), then size worker_connections to match or slightly exceed the FPM pool capacity, then model ad traffic cache bypass load (NODE 015) to validate that the PHP-bound concurrency ceiling is sufficient for campaign burst scenarios.