Allocation time to live (TTL)
Note: The content on this page pertains to Game Server Hosting (Multiplay) available on the Unity Cloud Dashboard. If you’re using Game Server Hosting (Clanforge), refer to the Game Server Hosting (Clanforge) documentation.
The allocation time to live (TTL) is a fleet-level setting that defines the maximum lifetime of an allocation. It primarily works as a safeguard for allocated game servers that are left idle. As players join and leave a game session, the game server must stay active to allow new connections. After a game server has been allocated for a certain amount of time without any player connections (the allocation TTL), it’s considered safe to shut down.
Different allocation TTL values can dramatically increase or decrease the resources your fleet uses and, by extension, the costs associated with the fleet. Games without persistent experiences have little need for extending the maximum lifetime of an allocation well past the default, so you can reduce the resources the fleet uses without much (if any) downside. On the other hand, games that offer persistent experiences benefit from extending the maximum lifetime of an allocation because it means that players can join and leave the game server over an extended time without worrying about losing their data.
Session length considerations
Warning: Setting long allocation TTLs to your game server could lead to higher hosting costs for your game. Please consider deallocating any game server not running an active session to prevent cost overruns.
The ideal allocation TTL balances flexibility and cost; the longer an inactive allocation remains alive, the higher the hosting cost. Games without persistent data that use short-lived sessions do well with allocation TTLs that range from minutes to hours. However, games (and other applications) with a persistent virtual experience benefit from longer allocation TTLs that range from days to months (and possibly longer). Because long-lived sessions have different characteristics than typical short-lived game sessions, scaling and game server placement can quickly become suboptimal when mixing short-lived and long-lived sessions. As a result, the recommended best practice is to have a separate fleet dedicated to long-lived game servers.
| Short-lived game sessions | Long-lived game sessions |
|---|---|
| Allocation TTL values range from minutes to hours, for example, 30 minutes. | Allocation TTL values range from days to months, for example, two weeks. |
| Don’t usually have persistent experiences. | Offer persistent player experiences. |
| Players don’t often leave game sessions and rejoin later. | Players are likely to join and leave game sessions at will, expecting their data to remain on the game server. |
The allocation TTL can also impact the performance of the game servers in a fleet. For example, a long-lived session might surface memory leaks that were difficult to find without long-running tests. Consider the following points when adjusting the allocation TTL:
- Ensure the allocation TTL reflects the maximum time you want a game session to run.
- Test your game server executable with long-run sessions before extending the allocation TTL to decrease the likelihood of unexpected memory leaks occurring with long-lived game sessions.
- Consider the expectations of your users before increasing the allocation TTL. Significantly increasing the allocation TTL might confuse some users.
- Use the Server Query Protocol (SQP) (or another query protocol) to ensure Game Server Hosting knows when the last activity occurred on each game server. If no player joins the game server, Game Server Hosting can deallocate it to save you costs. When a player joins, the countdown resets and restarts when the active number of connections drops to zero.
Fleet overrides
You can set and manage the allocation TTL for each of your fleets through the API.