Estimating Concurrency and JVM Tuning for High‑Traffic E‑Commerce Order Systems

When a major promotion approaches, an e‑commerce platform handling billions of daily visits needs to estimate the order system's concurrent load and configure JVM parameters accordingly.

Based on an average of 20‑30 clicks per user, daily active users are about 5 million; with a 10% order rate this yields roughly 500 k orders per day. Under normal traffic (three peak hours) this translates to about 46 orders per second, while a flash‑sale scenario (e.g., Double 11) can reach around 866 orders per second, requiring each of three servers to handle roughly 400 orders/s.

Assuming each order object is 1 KB, 400 orders/s generate 400 KB of order data. Accounting for related objects (20×) and additional operations (10×) expands this to about 80 MB of objects per second, which become garbage after one second.

A typical 4‑core, 8 GB server might allocate 3 GB to the OS and 5 GB to the JVM, with a 3 GB heap (Eden 800 MB, Survivor 100 MB each), 512 MB metaspace, and 1 MB per thread stack. This configuration can quickly fill Eden during peak load.

With 80 MB/s of new objects, Eden fills in roughly 10 seconds, triggering a Minor GC. Objects surviving in Survivor that exceed 50 % of its size are promoted to the old generation, causing Full GC after about 25 Minor GCs (≈25 seconds), which is undesirable.

To mitigate this, the young generation can be enlarged to 2 GB (Eden 1.6 GB, Survivor 200 MB each) and the old generation reduced to 1 GB. Eden then fills in ~20 seconds, allowing Minor GCs to reclaim most objects before they reach Survivor’s half‑capacity, preventing promotion to the old generation and dramatically reducing Full GC frequency.

The article concludes with the recommended JVM settings (illustrated in an image) and emphasizes the importance of data‑driven analysis for reliable system performance.