Hi, I was going over the Data Stores article and had a few questions.
The article states that for server limits SetAsync requests per minute is “60 + numPlayers × 10”. So, for example, if I had a server of 25 players, the limit would be 310 requests per minute. Meaning, if I wanted to push data for each player if, say, the server shutdown, this would be no problem? (I think)
In addition, the article lays out “Experience Limits”. It states that SetAsync is on a 6 second cooldown? Does that mean, if the server shuts down, I need a 6-second wait time? That doesn’t really make sense to me.
Its just depends on how often you are saving the players data into DataStore.
Depends on how big could be your servers, how many requests you are sending to DataStoreService. Exactly when you are handling this? on a loop each certain amount of time? when players leaves?
Glad you are not using thet Profile thing stuff. Its way better you can handle your own database without depending those tools
Is it really that bad though? If your reaching the rate limit on it then the way you manage your data is clearly bad. Really max you should be only really have a few datastores (for example one for the player stats, one for global stats or whatever u need). Then really all you would need to use SetAsync is when a user leaves the server so I don’t see how massive games should be reaching the limit. Also it is request per minute so how the hell are you going to meet the limit on that? Max you should be doing is saving data ever 5 minutes or something to reduce the chance of the code messing up if you don’t just save when a player leaves.
You mean using DataStores is BAD for massive games?..
That has no sense cause Profile"Service" thing uses datastores… that thing its just the easy way for someone that doesnt understand how DataStoreService works…
The limit is per key, meaning if you’re setting to the same key, you need a 6 second cooldown. However if they’re different keys, the cooldown is separate.
This should not massively affect you because there is a low chance your going to set the same key many times in a row (and leaving would be diffrent keys you set for each player).
You do understand the limit is per server right? It is not per experience so still this would not affect anyone. Reason why it is called “Server Limits” not Experience Limits
Even with games that have a large server number, due to the limit being based on a calculation rather then just a fixed limit as the server number increases so does the amount of requests you can send causing no issues.
Im not against using ProfileService… but, thinking that you cant handle a “massive game” without using it has no sense… I handled a game with 50k players without any issue without using ProfileService, its just about how you use the DataStoreService and if you understand how it works…
To me, using those tools its just being lazy on understanding how things works, “massive”, yeah, lets create a module that makes your game “massively popular” if you use it, things are easier to achieve your goal…
Using DatastoreService its not bad for 10m players splitted in thousands of servers, its not bad for a server that has a large amount of players too, it just depends on how you use DataStoreService. ProfileService its just a smat use of Datastore skills, at the end if you create your own “ProfileService” you are safe.
That calculation is unfortunately not right. According to math you need to follow the PEMDAS rule which means the calculation is actually done as such: 60 + (numPlayers x 10) which means if you have 25 players the final answer is 310 requests per minute.
This would not be a problem since you’re not saving twice on the same datastore key. This is assuming of course that your datastore keys / indexes are the players user ID (which they should be). Otherwise you’d run into the 6 second cooldown.
For that you’d want to create each coroutine task in the BindToClose ‘handler’ method which leaves the games shutdown signal to yield for a set number of seconds. This would save the data asynchronously because you’re running the saving logic within coroutines which are separate threads. This way you’re not synchronously saving and waiting for each players data to save until you move to the next player to save their data, it becomes incredibly slow.
So in a nutshell your game won’t shutdown for say 30 seconds which leaves plenty of time to save all the players data.
