BACKND Price Optimization Guide
Common
1. Use a handler for game maintenance and checking for logins from other devices
BACKND provides handlers for errors that must be checked on a regular basis.
Instead of repeatedly calling a BACKND method at certain intervals, such as every 1 second, to check the corresponding error, it is recommended you use a handler.
Invalid logic
A logic that calls the Backend.Utils.GetServerStatus() method every 1 second to check the project status value
Recommended logic
A logic that displays the UI related to maintenance upon a response from the Backend.ErrorHandler.OnMaintenanceError handler
2. Fixed data, such as charts and My game information, are only called for the first time.
Types of data that rarely change, such as loading charts(Backend.Chart.GetChartContents) or loading My game information(Backend.GameData. GetMyData), may cause the DB read load to increase due to their volume. Therefore, it is recommended you minimize their calls.
Invalid logic
Whenever saving the data, My game information is called and saved after adding the client data
Recommended logic
Immediately save the client data
Invalid logic 2
Every time the user visits the shop, the method to load the chart related to the shop item is called
Recommended logic 2
The method to load the chart related to the shop item is called the first time upon login and the data is cached for use.
3. Refrain from automatically recalling BACKND methods when an error occurs
In the case of an exception or a non-specified error during BACKND error logic processing, if the logic is supposed to recall until it succeeds, a permanent error occurs in cases such as server maintenance and access token termination, and costs are incurred for calling 'other items.'
Invalid logic
Process errors according to the developer documentation using an if statement and use a loop within the else statement for other errors
Recommended logic
Process errors according to the developer documentation using an if statement and display the error through the UI, and stop the game within the else statement for other errors
Game information management
1. Use Update instead of Insert to renew data
BACKND recommends that each table has separate data(row) for each user.
If a logic that continuously creates data(Insert) is used instead of the logic that overwrites the same data(Update) for data backup and operation, costs for storage and backup increase.
It is recommended you back up the data using the game log function, which can automatically delete data.
Invalid logic
Data is newly created every 5 minutes using Backend.GameData.Insert("Table", param)
Recommended logic
Save the indate, then overwrite the data using Backend.GameData.UpdateV2("Table", param, indate, Backend.UserInDate)
2. Configure the save logic according to the priority of the data
For the logic that saves data when the gamer gains an item, defeats an enemy, or progresses to the next stage, save calls can occur frequently depending on the game speed of each user.
Thus, the way of saving must be configured differently according to the priority between pieces of data.
It is recommended you save mail data immediately because it is removed after being claimed.
It is also recommended you save the claim of items purchased in the app because a repayment process is required if the data fails to be saved.
The purchase of items with in-game currency, the use of currency, and other similar pieces of data return to their original states and become available for purchase again, even after data rollback. Therefore, it is recommended you save such data according to the interval of the auto-save, where all changed information is saved at once.
Invalid logic
Saved whenever gaining an item, earning EXP, or defeating an enemy.
Recommended logic
Items, EXP, and enemy defeat counts are used as cached values and saved at certain intervals.
Immediately saved in cases where calls are limited, such as mail and receipts.
3. Set the data saving intervals in minutes instead of in seconds
BACKND recommends setting the auto-save interval to 5 - 20 minutes.
Suitably set the recommended interval according to the way of operating your game.
Invalid logic
Call the save coroutine every 10 seconds
Recommended logic
Call the save coroutine every 10 minutes
(If a call is not absolutely necessary, it is recommended to set a longer save interval.)
4. Use the transaction function when saving or loading multiple pieces of data
When a data saved method(Update) and lookup(Get) method are called for each table, there will be too many calls.
To save multiple pieces of data at once, use the transaction function, which saves up to 10 pieces of data in a single call.
Invalid logic
In a logic that saves every 10 minutes, the Backend.GameData.Update method is called according to the number of tables.
Recommended logic
In a logic that saves the data every 10 minutes, add the data from each table to the transaction list and put the list in the Backend.GameData. TransactionWriteV2() method to save with a single call.
Ranking
1. Refrain from calling the ranking loading method every time the ranking UI is displayed
In the case of a logic that calls the ranking loading method whenever the ranking UI is displayed, the interval of calling the load ranking method may differ depending on the user, which may lead to an excessive number of calls. It is recommended you reduce the number of calls by using a logic that renews every 5 to 20 minutes through caching instead of using a logic that calls whenever a ranking is shown.
Invalid logic
Call Backend.URank.User.GetRankList() and Backend.URank.User.UpdateUserScore() and apply them to the UI every time the ranking UI is displayed
Recommended logic
Check the time Backend.URank.User.GetRankList() and Backend.URank.User.UpdateUserScore() are called when the ranking UI is displayed.
Call again after 10 minutes, cache the data, and apply the cached data to the UI.
If 10 minutes have not elapsed, apply the cached data to the UI.
Mail
1. Do not use the previous mail method(Backend.Social.Post.GetPostListV2)
Backend.Social.Post.GetPostListV2, the previous mail management method, brings and excludes up to 100 pieces of mail for each call, causing the DB read load to increase as the amount of mail increases.
To implement the mail function, please use the new mail method.
Guide documentation: https://developer.thebackend.io/unity3d/guide/upost/info/
2. Do not use a logic that loads mail at short intervals to implement mail notifications
There are some cases in BACKND console where the load mail method is repeatedly called every 1 - 60 seconds immediately after a piece of mail is sent to notify the users that the mail has been sent. Because BACKND does not support real-time notifications between the console and client, it is recommended you make the call every 20(or 30) minutes for your implementation, not in a unit of seconds.
Invalid logic
Call Backend.UPost.GetPostList(PostType.Admin, 10) every 1 - 10 seconds
Recommended logic
Call Backend.UPost.GetPostList(PostType.Admin, 10) every 20 minutes
Guild
Refrain from calling the guild and guild ranking methods whenever displaying the guild UI
Initiating "Load my guild information"(Backend.Guild.GetMyGuildInfoV3) and "Load guild ranking"(Backend.URank.Guild.GetRankList), whenever you create a UI related to guild information may increase your costs drastically.
Identical to the ranking function, it is recommended to use a logic that caches the loaded value and sends a call request again after a certain interval has elapsed or when the user leaves the guild.
Invalid logic
Call the relevant guild method whenever the guild UI is displayed
Recommended logic
Upon the creation of the guild UI, compare the time with the latest time when the ranking information was loaded; if less than 5 minutes have passed since the last call, the UI is configured with the cached value.
When 5 minutes have passed, go through recall and caching, and configure the UI with the cached value.
Game logs
Adjust the storage period for data that does not need to be kept for long a long time
If the graceDays(grace period) is not specified when inserting the game log, it is automatically set to 90 days.
The period is calculated as storage costs because the data exists on the server for 90 days. If you decide that 90 days of storage is unnecessary, adjusting the period to 7, 15, or 30 days is recommended.
Invalid logic
Backend.GameLog.InsertLog("logType", param) Call without designating graceDays
Recommended logic
Backend.GameLog.InsertLog("logType", param, 15) Call after setting graceDays
If auto-save is used at certain intervals, take caution of storage and DB writing costs
Because the game log management only provides data insertion, storage and DB writing costs increase according to the number of calls.
With this in mind, it is recommended you save logs for only necessary information, such as errors and in-app purchases.
Random lookup
Do not use the previous random lookup method(Backend.Social.GetRandomUserInfo)
In the case of Backend.Social.GetRandomUserInfo and Backend.Guild.GetRandomGuildInfoV3, the previous random lookup methods, the search continues until the condition is met in the DB data. Using such methods leads to a higher measurement of response time and DB usage according to increased data.
To implement the random lookup, use the random lookup method(Backend.RandomInfo.GetRandomData) which has the above problem fixed.
Invalid logic
Use the Backend.Social.GetRandomUserInfo method for the random lookup method
Recommended logic
Use the Backend.RandomInfo.GetRandomData method for the random lookup method