Hi,
I’ve done lots of testing and created a library (GitHub - arxkdev/Leaderboard: Leaderboard is an intuitive, open-source module designed to effortlessly establish and manage robust non-persistent & persistent leaderboards for your Roblox experiences.) meant for streamlining the creation of timed global leaderboards, but the limits for MemoryStoreService are just not feasible to be working with Global Leaderboards, most especially timed ones.
Sharding only works to a very limited extent where you wont have to worry about hitting the size limits, but you will have to worry about the request units you are using per minute across ALL the shards. Something I didn’t realize was that the request limit is subject to the whole experience, not individual maps. This makes working with sharding/partitioning near impossible with this type of use case. Let alone not having any way to request the budget so we cannot adjust our systems accordingly.
Request unit for all (experience) API calls: 1000 + 100 * [number of concurrent users]
Scenario:
Say you have 3 board types for a single stat: "Money"
Board 1: Daily - 1 Shard
Board 2: Weekly - 3 Shards
Board 3: Monthly - 5 Shards
For a total of 9 shards
1 CCU: this is 1,100 request units/minute for all API calls.
200 CCUs: this is 21,000 request units/minute for all API calls.
Average server size 8-20, say ours is 10.
20 Servers (200 CCUs / 10 server size), each server:
- Runs every 90-120 seconds
- UpdateFunction → Saves 10 UserIds (30 Request Units)
- GetRangeAsync → Collects top 100 (900 Request Units)
- We have 9 shards, that’s 900 request units for get and 30 request units for update/set.
- 930 request units for that server
- Out of all 20 servers, that’s 18,600 request units/minute
Keep in mind our threshold is 21,000 request units per minute.
You’re probably wondering, what If I wanted to add another leaderboard for say "Wins" or what if I want to add another board type, like Hourly?
Answer: You can’t. Do all those calculations and x2 it, 37,200 request units per minute for a threshold of 21,000 request units per minute. In fact, I would be doubtful you could create just ONE board without experiencing random internal errors and random miscalculated rate limiting (??)
This was mentioned in the documentation:
Why is it mentioned that Sharding helps with request limits? It does not. All it did was widespread the issue and solve usage limits.
Random errors I get 7/10 times using MSS (not sure if they’re related to the limits being hit or not):
TL;DR
- MemoryStoreService with Global Leaderboards (or in some cases, as a whole) is extremely choppy
- Why is Sharding/Partitioning recommended if all it does is solve map size limits and not also request limits for an experience?
- A request budget feature similar to DatastoreService would be nice
- MemoryStoreService API calls fail a lot, making it hard to stress-test, or test at all
- MemoryStoreService API miscalculates the rate limits a lot. Again, a budget would help with debugging this
- My library (above) is rendered useless if all it can support is 2 leaderboards with 2-3 board types in each without hitting limits