Load test summary: so-gasing.id /play/

15 October 2026, 14:45 to 15:46 WIB, against production (https://so-gasing.id)

Open the full JMeter report

The short version

How the test was set up

120 threads came from the projection of 600,000 registered users. Using the defaults in load-calc.py (20% active per day, 30% of those in the busiest hour, 20 minute sessions), that gives about 12,000 students online at the same time, or around 30 page loads per second. Each virtual visitor reloads /play/ every few seconds, much more often than a real student, so 120 of them are enough to create that traffic.

Which endpoints we tested and why

Every virtual visitor repeats what a real browser does when a student opens https://so-gasing.id/play/. The page makes three API calls by itself every time it opens, so we included all of them. If we only tested the HTML, the server would see about a quarter of the real number of requests.

All four requests are wrapped in one transaction called "Open /play/ (full page load)", so the report also shows the total time a visitor waits.

What we left out on purpose: anything that writes data (saving progress, profile updates, checkout) or needs a login, so the test did not create junk data in production. JMeter does not run JavaScript, so the game itself was not played. Images, scripts and other static files were skipped because Cloudflare serves those from its cache and they would mostly measure Cloudflare, not our server.

Results per endpoint

"Median" is the typical time. "95th pct" means 95 out of 100 requests were faster than this number, so it shows what the slower visitors experience.

The test downloaded about 2.2 MB per second (around 18 Mbps). That is well within what one laptop and a normal internet connection can handle, so the errors come from the server side and not from the test machine.

What went wrong with the leaderboard

How it played out over the hour

• 14:45 to 14:51 WIB, ramping up. With only a few visitors, the leaderboard already failed about 60% of the time, mostly with 500 errors after around 10 seconds.
• 14:51 to 15:04 WIB, leaderboard down. Every leaderboard request failed with a 502 or hung until the 60 second timeout. The average leaderboard time went up to about 40 seconds. Because visitors were stuck waiting, the whole test slowed to fewer than 3 page loads per second.
• 15:04 to 15:46 WIB, partly back. The leaderboard started answering again without any change on our side, but 35% to 85% of requests still failed in every 5 minute window, mostly with 500 and 429. The last 15 minutes were the best, with about 35% to 40% failures and a typical response under 1 second.

What this means

• The leaderboard is the bottleneck. Everything else on the page is ready for this level of traffic.
• The test did not reach the planned load. We aimed for about 30 page loads per second. Because every visitor had to wait for the slow leaderboard before starting the next visit, the test only averaged 9.5 per second, and about 18 per second at its best near the end. The server saw around a third of the planned traffic and still struggled, so at the full planned load it would likely be worse.
• Real students may already be affected. The leaderboard failed even with a handful of visitors, so it may also fail for real students during normal traffic, not only during this test.
• Some 429 errors may be caused by the test itself. All test traffic came from one IP address. If the rate limit is per IP, real students on many different IPs would not hit it as quickly. If the limit is global for the endpoint, real students would hit it too.

Files in this folder