The Problem We Were Actually Solving
On my servers, I've been trying to hit a certain latency threshold for players while maintaining a high population – this means around 60-80ms latency with 200-500 players online. Easy enough, right? Well, it turns out that the TRE is actually the biggest offender when it comes to creating lag. When a player starts or joins a treasure hunt, the TRE sends a whole bunch of information back to the client – including the treasure's location, the hunt's ID, and the player's status. Sounds innocent enough, but in reality, this packet is around 200 bytes and is sent every 5 seconds for the duration of the hunt. That's a lot of data moving around the network.
What We Tried First (And Why It Failed)
We started by tweaking the packet size – reducing it to 100 bytes or even 50 bytes – thinking that this would alleviate some of the pressure on the network. However, the problem wasn't the packet size, it was the frequency of the packets. Every 5 seconds, the TRE would send out the packet, causing the server to spend more and more time processing and sending the updates. We also tried to optimize the server-side code, using caching and reducing the number of database queries, but the issue persisted.
The Architecture Decision
I realized that the real solution lay not in tweaking the TRE's behavior, but in re-architecting the whole system. Instead of sending the treasure's location back to the client, we decided to store it in a separate cache on the server-side. This way, when the client requests the location, we can simply return the cached value, rather than querying the database. We also reduced the packet frequency to every 15 seconds, which gave the server some much-needed breathing room.
What The Numbers Said After
After making this change, we saw a significant reduction in latency. Average latency dropped from 70ms to 45ms, and the server was able to maintain a steady population of 500 players. The allocation count for the packet sending code also dropped by 20%, which was a nice bonus. We also monitored the CPU usage and saw a 10% reduction in processing power devoted to the TRE.
What I Would Do Differently
Looking back, I wish we had tackled the problem from the start by focusing on re-architecting the system, rather than tweaking the parameters of the TRE. While tweaking parameters can be a useful short-term solution, it often masks the underlying issue and leads to more problems down the line. In the end, it's always better to take a step back and think about the system as a whole.
Top comments (0)