How many seconds should I wait for GetAsync so it doesn't throttle?

Help and Feedback Scripting Support
#1

How long can I wait between periods to attempt at loading the player’s data when they join?

I’m working on a very intense game and I need to make sure the loading is consistent but doesn’t take too long to load.

I know for SetAsync the minimum wait time is around 30 seconds per request. What I don’t understand about it though is that you have to save the player’s data when they leave the game if you want the save to be instant. So if a certain amount of people just up and left the game it would cause throttling.

1 Like
#2

Throttling only happens with SetAsync if you request the same key too quickly, or reach the overall limit, which is based on the current player count. Basically, if a bunch of players left at the same time, everyone’s data would be able to save at once, as long as the overall request limit isn’t met (unlikely).

2 Likes
#3

I didn’t know this I thought it throttled from any key in general just the use of the code.

#4

There are a lot of elements at play when dealing with Datastores such as backlogged budgetting and read caches, but if you take a look at the server limits within the docs you’ll find the following formula: 60 + numPlayers * 10.

I usually disregard the hard 60 and assume that each player in the game can make a GetAsync request every 6 seconds at maximum. If you’re looking to make an autosave feature, go for something like every 60 seconds which will give you plenty of enough allowance for any other needed tasks.

The player’s data should be requested as soon as they join.

There is a read cache for GetAsync operations performed on the same key. If you’re trying to add retry logic in case the player’s data fails to load, then be extra safe and wait 10+ seconds (or so) between each retry. To be extra extra safe, kick the player with a “data failed to load” message after reaching several attempts to prevent data loss.

Note: there is an option to disable the cache, but the majority of developers won’t need this option.

Unlikely. Unused Datastore budgets are added to a backlogged budget up to a maximum of 3 times the normal highest limit. Both the backlogged budget as well as the normal Datastore budget scales depending on the number of current players. This information is courtesy of BuildThomas.

You shouldn’t ever have any problems if the following workflow is used: get player’s data, cache player’s data in a table, make immediate changes to cache, periodically update the player’s Datastore key by using the cache, and save the Datastore key when the player leaves by using the cache.

#5

Throttle don’t mean it isn’t going to work … it just got put in a queue for a bit.
It will go through in a second or two. Only when you get a ton of them in a row, it may not go through. Shouldn’t be hammering your datastore. Only need to call it twice per player. When they enter and when they leave. Everything else should be handled with variables. If you have a leaderboard updating off the datastore call that with a gap … like 3-5 minutes. Avoid things like datastore value = datastore value + 5. Do datastore value +=5 … it’s that double read on the same value that gets you.

#6

Yeah I know throttling doesn’t stop the datastore from working, but throttling still can be a problem. If the player leaves during the queue period, and joins another server. But that’s only for saving data, and you could probably just use a number variable and add it each time you save perhaps as a version. Maybe keep the old data too in case it doesn’t update you can revert to the latest save before the error occurred. I don’t know much about data versions but I heard it can be useful for restoring data as well. You can set players back manually or just have even the script do it.

#7

Hello
I’m late, but…
to throttle something like setasync would require

for i = 1, 3, 1 do
task.spawn(function()
ds:SetAsync()
end)
end
-- this happens to be a very poor use of setasync, but even if it is..
-- It's not even that bad, it'll just become a warning and be put to queue (up to 10 queues I'm assuming)
-- I'm very certain you get 1 free use for setasync every 1-2 seconds,
-- check your budget with datastoreservice:requestbudget
-- it's very unlikely to lose all your setasync budget even if you used setasync 30 times every minute
-- surprising right?
-- now if for i = 1, 3, 1 do was for i = 1, 50, 1, do 
-- it would error if you still used task.spawn
-- what I'm saying is you should have a module that regulates all data managing
-- i doubt you need one unless your game is heavily based on datastoreservice which is extremely rare
-- example: 
for i = 1, 100, 1 do
datastore:SetAsync(key,{})
end
-- the code you are seeing right now will not error at all because setasync has its own "yield" feature
-- meaning, it will wait until setasync is successful.
-- Keep in mind the budget is something you can play with, just don't mess up the queues
-- you get to use one set async for every 1-2 seconds
-- don't worry because I'm pretty sure you can use setasync 300 times for 5 minutes straight as long as you don't setasync at the same time

The budget for each dss feature is big, you can look into dss:GetRequestBudgetForRequestType()
one point = one use, from my tests i got more than 200+ setasync in a singleplayer server, i believe getasync has more budget than setasync too

1 Like