How to Tame High Concurrency: Front‑End Tricks and Server‑Side Optimizations

1. Rising Number of Concurrent Connections

Web systems now encounter exponentially growing concurrent connections, making high concurrency a norm and a serious challenge. Simply adding more machines or upgrading hardware is costly; technical optimizations are essential.

The surge is not due to user base growth but to richer pages and more interactions. Modern homepages, such as www.qq.com, generate hundreds of requests per refresh, plus periodic background queries.

Long‑living HTTP keep‑alive connections reduce connection churn but occupy server resources when idle, and WebSocket connections keep them alive even longer.

Browsers have also increased per‑domain connection limits from 1‑2 to 2‑6, accelerating server load and creating high‑concurrency peaks during traffic spikes.

2. Front‑End Optimizations to Lighten Server Load

Effective front‑end techniques can cut or ease HTTP requests.

Reduce requests : Use Cache‑Control headers (expire, max‑age) to store static assets locally, and leverage HTML5 LocalStorage for client‑side caching, eliminating many server hits.

While this greatly reduces server traffic, it does not help first‑time visitors and may affect real‑time data.

Lighten requests : When cached resources expire, the server can respond with 304 Not Modified using Last‑Modified or ETag headers, avoiding full data transfer.

Even with 304 responses, a connection is still established.

Merge page requests : Inline CSS/JS to avoid separate downloads, batch multiple Ajax calls into one, and combine small images into sprites to cut the number of HTTP requests.

3. Saving Server Memory

Memory is a critical server resource. It is consumed by connection bookkeeping, buffer storage, and runtime allocations.

Apache’s evolution illustrates memory‑saving strategies:

Prefork MPM : Stable but each child process copies the parent’s memory, leading to high per‑process memory usage and limited scalability under high concurrency.

Worker MPM : Mixes processes and threads; threads share memory, reducing footprint, but still suffers from long‑alive connections occupying threads.

Event MPM : Introduces a dedicated thread to manage keep‑alive connections, freeing worker threads for active requests and further lowering memory usage.

Lightweight servers like Nginx use a single process to handle many connections, naturally consuming less memory than Apache.

The sendfile system call further reduces memory copies by transferring data directly from kernel buffers to sockets.

4. Saving Server CPU

CPU consumption arises from context switches, I/O multiplexing, and lock contention.

Select/Poll repeatedly scans all socket descriptors, which becomes costly as the number of idle descriptors grows.

Epoll registers interest events with the kernel, delivering callbacks only for active sockets, dramatically reducing CPU work under typical high‑concurrency workloads.

Thread‑based servers also incur context‑switch overhead. Nginx’s model—one master plus a few workers handling many connections—minimizes such switches.

Multi‑threaded modes introduce lock contention; careful lock ordering or avoiding locks (e.g., thread‑local copies of globals in PHP) mitigates CPU impact.

5. Conclusion

While Nginx + PHP‑FPM often appears the most resource‑efficient stack, the optimal architecture depends on specific business requirements. Continuous evolution of web servers strives to handle more requests with fewer system resources, offering valuable patterns for developers and operators alike.