Optimizing Web Server Performance for High Concurrency: Front‑end Techniques and Server‑side Strategies

In recent years the number of concurrent connections to web systems has grown exponentially, making high concurrency a normal condition that strains servers. Simply adding more machines is costly; combining technical optimizations is a more effective solution.

The increase is not due to a larger user base but to richer pages and more complex interactions. A typical homepage such as www.qq.com generates hundreds of HTTP requests, many of which are kept alive for long periods, occupying server resources even when idle. WebSocket connections add further long‑lived traffic.

Modern browsers also raise per‑origin connection limits from 1‑2 to 2‑6, accelerating the pressure on back‑end resources during peak traffic.

Front‑end optimizations aim to reduce server load. Caching static assets via Expires or Cache‑Control: max‑age headers, as well as using HTML5 LocalStorage , eliminates many requests after the first visit. Conditional requests using Last‑Modified or Etag allow the server to reply with 304 Not Modified , avoiding full data transfers.

Request merging further cuts traffic: embedding CSS/JS directly into HTML, batching multiple Ajax calls into a single request, and combining small images into CSS sprites all reduce the number of HTTP connections.

Server‑side memory savings focus on the three main memory consumers: connection‑maintaining structures, data buffers, and runtime allocations. Apache’s evolution illustrates memory‑saving strategies:

1. prefork MPM creates many full processes, each copying the parent’s memory, leading to high per‑process memory usage and limited scalability under high concurrency.

2. worker MPM mixes a few processes with many threads, sharing memory between threads and reducing overall consumption, though it introduces thread‑safety concerns.

3. event MPM adds a dedicated thread to manage keep‑alive connections, freeing worker threads for active requests and further lowering memory usage.

4. Nginx adopts an event‑driven, single‑process‑multiple‑connection model that inherently uses far less memory than Apache.

5. sendfile bypasses user‑space buffers, copying data directly from kernel buffers to the network socket, saving both memory and CPU cycles.

CPU optimization addresses the cost of context switches and I/O multiplexing. Early Apache versions relied on select / poll , which require scanning all file descriptors and become CPU‑intensive as connections grow. epoll registers interest only in active descriptors, dramatically reducing polling overhead.

Thread‑based models (Apache worker/event) still incur context‑switch and lock overhead, while Nginx’s process‑based model minimizes these costs. Proper lock ordering and avoiding unnecessary locks are essential to prevent deadlocks and starvation.

In summary, while Nginx + PHP‑FPM often yields the most resource‑efficient setup, the optimal architecture depends on specific business requirements and workload characteristics. Continuous evolution of web server technologies strives to handle more requests with fewer system resources.