If one action needs several server round trips one after another, your ping is multiplied by that many.
Why Open shop → request list → check price → buy → refresh inventory, each as a separate request → Effect Each request is sent only after the answer to the previous one arrives → On screen At 150 ms ping, a single purchase takes close to 1 s. Loading takes unusually long
During specific actions, Right after login or maintenance
Owner
Primary owner Game team (Server development) · Also Game team (Client development)
Game team action items
Server: change the protocol so several steps go in one request and response (e.g., include the updated inventory in the purchase response). Client: fetch the data you’ll need ahead of time, use UI that doesn’t wait for results.
Ballpark numbers
Time taken ≈ number of round trips × (ping + server processing + tick wait). With 5 round trips at 150 ms ping, about 0.85–1 s.
On the graph
Always high · Completion time per feature, round trips per action
Where to look
Server-side packet capture (Wireshark) while a test account performs one action such as a shop purchase or login, counting how many times requests and responses alternate and the gaps between them. With server request logs, group by session ID and look at the request count and each request’s arrival and response times
Confirmed if
One action sends several requests in turn, each waiting for the previous response, completion time is roughly round trips × RTT, and the same feature is proportionally slower for players in high-ping regions
Ruled out if
Only one or two round trips but one response takes a long time: points to server processing or the DB. All players equally slow regardless of ping: check server load
Check with
Infra tools (no game code needed)
Sources
Chatty I/O antipatternMicrosoft Azure Many small I/O requests add up to latency that badly hurts responsiveness; recommends fewer, larger requests