This simply calls UpdateAsync every 6 seconds, and displays the log and budget on a surface for your convenience.
When testing with 3 active server instances, I started experiencing throttle warnings on every single request after the first few requests on one of the servers. The save data was about 13Kb, well within the size limits of a store and 6 seconds since the last call.
I noticed that there was an updated value printed (that’s the body of the UpdateAsync function) that did not have a corresponding “Calling UpdateAsync” print, which then hit the throttle and ruined all further requests. I don’t know where that phantom update call came from, as my code did not call it else there’d have been a print to go with it.
My theory is that UpdateAsync can sometimes retry(?) and cause itself to throttle since the retry is within the 6 second cooldown.
I expect Datastores to function according to their documented limits.
Actual Behavior
They throttle unexpectedly, potentially leading to data loss.
Workaround
None. In fact, other big developers (ScriptOn, PeZsmistic, Chipio, Noble_Draconian, Aaron_Mccoy, filiptibell, Pavalineox) have told me that they have experienced this as well, and I am sure there are countless others who have too.
Issue Area: Engine Issue Type: Other Impact: High Frequency: Sometimes
Hey @boatbomber, can you elaborate more on the specific end use case you are trying to achieve? We want to understand the problem you’re trying to solve to determine if this should fall within reasonable datastore limits or if the problem should be solved with another approach or another data-related service we provide.
Generally speaking, without knowing more about your problem, sending many writes to the same key in the same time interval will lead to throttling.
Ah yes, I know this one. I can explain it, yet I have no valid fix.
Every time you set an async it sends the request to the server of Roblox. Now if you keep sending them the server will have to wait because of the Data store queue. Every request has to be processed and stored and that can cause a lot of waiting in line.
I understand the need to avoid making keys too hot. Datastores define an upper limit on heat at 6 seconds before requiring the cooldown. I was under the impression that anything 6 seconds or less would be supported as being warm and perhaps not ideal, but not hotter than Roblox was agreeing to handle. When writing according to the officially documented heat limit, you are unexpectedly throttled.
Just to make sure I fully understand, you are only seeing the throttle warnings when multiple servers are hitting the same key in the same store, each on a 6 second interval? (so in your situation with 3 servers, effectively, a 2 second interval if seen across the experience’s servers) Or are you adjusting the time interval based on the number of active servers?
Looking over the docs, I think I see where the confusion comes from. We used to list out at the 6-second write time between requests that this applied per-key across the experience rather than per server, but the current version is not clear enough on this part.
We’ll get these docs adjusted so that this is more clearly documented, apologies for the inconvenience.
Datastore service is best used when you’re writing relatively infrequently to many different keys, for example when storing player data or leaderboards. For approaches where you need a central blob of data that is shared between many servers, we would recommend that you split your data over multiple units of storage instead of one key, and consider using one of the other services Roblox provides such as Memory Store. This one sacrifices durability for increased availability and throughput, which seems more suitable for solving your problem.
If you feel that your use case is not sufficiently covered, feel free to file a topic in #feature-requests with your problem and our teams will look into it.
Oh, that makes more sense. Yeah, those docs are very misleading. The limit is literally written in the “server limits” tab with “Each server is allowed a certain number” written on it.
