Performance Optimization of a High‑Concurrency Web Service: From Bottleneck Identification to TCP Time‑Wait Tuning

The article records a performance‑optimization case study for a high‑concurrency web module that was split from a main site to avoid overloading the core services. The original requirements demanded at least 30 k QPS, database usage under 50 %, server load under 70 %, request latency under 70 ms, and error rate below 5 %.

Initial analysis highlighted that the system heavily relied on database reads and writes for popup configuration and user interaction tracking, leading to connection exhaustion and high error rates when QPS approached 6 k. The author emphasized that optimization must be goal‑driven and aligned with real business needs.

To alleviate the database bottleneck, a Redis‑based FIFO queue was introduced to offload write operations, and later the entire configuration data was cached, falling back to the database only on cache misses. Architectural diagrams (original images) illustrate the before‑and‑after designs.

Load‑testing with Locust showed that after the first round of caching the QPS plateaued around 20 k, CPU usage 60‑80 %, and database connections stabilized at ~300, but TCP connection limits still constrained further scaling.

Investigation revealed that many TCP sockets remained in TIME‑WAIT state, preventing reuse. The author adjusted Linux kernel parameters to reduce TIME‑WAIT buckets and enable fast recycling and reuse:

# timewait count, default 180000
net.ipv4.tcp_max_tw_buckets = 6000

net.ipv4.ip_local_port_range = 1024 65000

# enable fast recycle
net.ipv4.tcp_tw_recycle = 1

# enable reuse of TIME‑WAIT sockets
net.ipv4.tcp_tw_reuse = 1

After applying these settings, the service sustained 50 k QPS, CPU around 70 %, normal database connections, TCP connections without blockage, average response time 60 ms, and zero error rate.

The conclusion stresses that web development performance is a multidisciplinary engineering problem involving application code, databases, caching, operating‑system networking, and that developers need solid fundamentals across these areas to diagnose and resolve issues effectively.