Useful Links

Context

With the issue of getting rate limited solved, it seemed like it’s smooth sailing for Nessie’s automatic map status updates to be finished. I probably thought that too soon though as when I finally go to the point of testing the actual status through webhooks, I realised it was taking too long to finish. For one cycle, it took 3 seconds from the start of the scheduler all the way to when it updates the database

Granted 3 seconds is not a long time for one guild but in the grander scheme of things, this cannot be sustainable in a large scale. We’ll find ourselves back in square one with all guilds taking hours to get their updates done

This doc will try to outline the time taken for each flow, so that we’ll know which one has the fastest time to finish as well as outlining the affected user experience. This would give us a better standpoint of choosing what is the best choice for automatic status and the approaches we can take to get there

Time Taken For Different Flows

We want to know what’s the maximum time it would take for one cycle of status to finish. We could just do for one guild but I think having more guilds would give us a better sense of what it would really be. I don’t really know how to automate this testing so I’m opting to just manually doing it in 10 different test servers and go from there

Since we want to see the maximum time, all of these have both battle royale and arenas modes selected for their status

Also all of this starts with getting all the status from our db and ending with updating our db; keeping the time taken for those still in as we want to know the max but listing it here for context

Time Taken

Approaches

From the above results, it’s pretty clear which ones are the best. Synchronous message creates and message edits are miles ahead of the rest. However since we don’t want a flurry of spam, editing is the way to go. Funnily, we’ve come full circle. We started with edits a long time ago, realised we were going to be rate limited so switched to creates + deletes, realised that wasn’t enough to bypass rate limiting so switched to webhooks and now we’re using webhooks to edit messages again lmao what a ride

Big caveat though since edits are the most resource extensive out of the rest. Message edits are rate limited to 3 per 20 seconds so this might be similar to webhooks albeit higher. We can go ahead with this approach for now as it’s the best UX + best time taken but we might have to think about a backup when things get unstable with more and more status gets initialised