oh wow, thats cool. Is there any plans to add a way to track this data? It’s impossible to manually do so.
Datastore limits use the same sort of quota system (based on the number of active players in servers) and still has an api to query budgeting. So MemoryStoreService having this API would be just as hugely useful.
1 Like
I made some calculations and I’m honestly concerned about the change.
In my game there’s a cross-server matchmaking system which puts the players into a sorted map (more comfortable implementation than Queues).
The starter servers are 8-player each with 3 slots reserved for friends.
Each 2 seconds each server makes GetRangeAsync request which returns all the joinable matches.
Now, according to what I’ve said above:
(matches_in_map * (60 / 2) + 60@) * lobby_servers >= min(1000 + 100 * players, 100000)
60@ are additional requests related to the matchmaker.
Now, using estimates and data collected so far by the testers I am able to replace the variables quite accurately using CCU variable. It would be:
(ccu / 35) * 30 + 60) * (ccu / 12) >= min(1000 + 100 * ccu, 100000)
Which gives ~ [1150, +inf] (this already uses 100k requests quota), meaning that 1150 would be the maximum concurrent user count in my game after this change. Actually, probably a little more because I used really safe estimates.
While I can only hope for my game to reach that ccu, it appears to be a huge problem for huge games.
Of course, I could increase this number by for example:
- increasing the delay between expensive requests
- increasing maximum player count per server
- adjusting other matchmaker settings
But it causes more inconveniences and still, will eventually exceed the new quota.
Therefore, my suggestions to change the current way of constraining the requests would include:
- force a delay between expensive requests (0.5 second for example), like in DS.SetAsync, as calling these functions on a single map/queue in a single server more frequently is a terrible practice anyway
- change the linear formula of calculating units of expensive requests to an sqrt function so for 200 results the unit count won’t exceed 50.
I hope there will be changes to the current quotas as they are harmful, especially for matchmaking systems.
4 Likes
What the current request per minute right now?
1 Like
Does this mean that DataStoreService 's
will be fixed? i.e making saving more effective and secure ensuring that no data is loss because too much data was saved at the same time?
1 Like
What does this have to do with the original post…?
Also, pretty sure that data doesnt get lost because of that, it just takes longer to save
2 Likes
Why are you making constant, expensive requests every 2 seconds? isn’t this REALLY wasteful for no practical changes at all?
3 Likes
Even with a heuristic value that isn’t always up to date would be useful. The main concern is avoiding request throttling and/or making sure core systems always remain stable.
Finally. Big games won’t crash other games anymore. Was incredibly inconvenient and unfair for everyone. I am tired of my memory stores breaking because some enormous game was crashing the system.
1 Like
That is not an issue that needs to be fixed. You are making too many requests too fast so it is queuing them so you do not exceed the limit. If you are losing data then it is your own fault.
1 Like
It would still be useful as we can write backoff algorithms that are all good citizens. Since we control all access patterns we can be smart as we approach limit.
2 Likes
So for example, if 20 players were to leave the game around the same time and triggers too many requests, would players lose data?
Just checked and this will absolutely kill my daily leaderboard in my experience, every minute the experience makes a request for the top 100 players, this means (with the 100,000 request limit per-queue) I will end up reaching the limit with only 100 servers, which albeit a large number it is not scalable like what Roblox tries to be. This also gives no lee-way for actually saving new data as that will need to make a request.
1 Like
Not if the queue isn’t full. Implement your own queue system if you want to protect against it. The message does say that further requests will be dropped if the queue fills.
When the queue get full? Like what is the specific limit requirement for it to start being full and dropping requests?
Hi, it’ll be actually 1000 servers to reach the limit. Could you explain why you need to query top 100 players every minute? Is it possible to query on demand instead of polling?
It’s nice to see the team working out the concerns we have with this as developers.
Oh, seems I can’t do basic maths anymore. 
I’ve still always been a person of scalability, if it doesn’t scale, I don’t like using it. This has seemingly also been in Roblox’s vision too (Datastore limits scale with player count and most MemoryStoreService limits too). Also, this number does not include any additional SetAsync requests I run to update player data too.
My experience uses MemoryStoreService as a daily leaderboard, the values are reset daily (by setting the timeout of the keys to the end of the day) and I need to poll the top 100 players every minute to display the most up to date information on the top users for the current day.
Unfortunately not for my use-case, the leaderboard has to update at a somewhat regular interval (as players leaderboard values will change decently often - once per day, per player when they join, in-which my game previously has hit hundreds of concurrents) and using MessagingService to query on-demand would make it fairly hard to code an efficient system that could make sure servers don’t de-sync permanently due to a single failed request or SubscribeAsync failing to connect.
If you would like further details on the implementation of this in my experience, please feel free to message me here on the DevForum. Just that sharing more in-depth information is both a lot of clutter here and likely irrelevant to most people viewing this topic. 
1 Like
Is it possible for the limit quota to switch to Server based instead of Experience?
When I found out about MemoryStoreService I thought of global events systems, for example collecting as many coins as possible together with all the players online in game, but it seems this idea isn’t possible with the current limits because the 100,000 requests per minute would be reached quickly, considering you have to loop requests to get the up to date value on all the servers and also request each time the player adds more into the value
since they have to be carefully hardcoded.
The biggest benefit here, you can update global leaderboards so fast!!
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.