Optimizing fleet size

Introduction

In AccelByte Multiplayer Servers (AMS), the number of dedicated servers in your fleet automatically scales up and down, following the fluctuating demand for servers as the player count varies between different times of the day. Scaling happens independently for each region. As such, you can configure a scaling strategy for each region you want your fleet to run dedicated servers in.

This guide walks you through how to configure the right scaling strategy for your fleet in AMS. Properly setting these values by always having enough dedicated servers ready to go ensures smooth player experience while also optimizing resource usage and cost.

Optimize fleet size

When creating or configuring a fleet, set its size in the DS Host & Region section. See step 9 in the creating a fleet guide.

All fleet scaling configurations are defined in the number of dedicated servers (not host instances). AMS automatically handles running the appropriate number of host instances.

An incorrect scaling strategy may lead to players being unable to claim a dedicated server. A common cause of such claim failures is an insufficient max, or buffer size. If you experience that your fleet isn't spawning as many DS as required, first ensure that your max is sufficient, before verifying your buffer size.

We recommend configuring the scale of your fleet as follows:

Dedicated servers per instance

Specify the number of dedicated servers per host instance in the Dedicated Servers field. Larger machines can accommodate more dedicated servers per instance.

Note that the fleet optimizes host instance utilization by rounding the minimum and maximum server counts (explained below) to the nearest multiple of servers per instance. This ensures efficient resource allocation and prevents unused capacity within host instances, which are billed to your account.

For example, with 5 servers per instance, a minimum of 3 servers, and a maximum of 28 servers, the fleet will adjust these values to 5 and 30, respectively.

Furthermore, if the buffer value requires an additional virtual machine request, all five dedicated servers within this new instance will be designated as buffers.

Max Servers

The Max Servers value defines the maximum number of servers that can run within a specific region. This value acts as a cost safeguard, preventing game server expenses from exceeding your budget. The value counts servers in all states: "Creating," "Ready," or "Claimed."

important

Max Servers is a hard limit. Your fleet will not scale beyond this number. Consequently, an insufficient value can lead to claim failures, where players are unable to acquire a dedicated server for their match.

A reasonable estimate for Max Servers is (at least) the number of servers required to accommodate the maximum number of concurrent players (peak CCU) you anticipate during peak usage periods.

• Formula: Max Servers >= Peak CCU / Players per Server

We recommend setting Max Servers beyond your anticipated peak CCU and as high as your budget allows. This approach ensures players can still obtain a dedicated server even if the peak CCU surpasses your initial estimate, while not incurring additional cost if the peak CCU does not surpass the estimate.

Min Servers

The Min Servers value specifies the minimum number of servers that should always be running within a region. This setting ensures a consistent number of servers are available to handle incoming player requests, even during periods of low activity.

For most scenarios, we recommend setting Min Servers to 0 and set a buffer instead. This configuration enables dynamic scaling, allowing your fleet to adapt efficiently to fluctuating player demand. However, during launches or events with anticipated sudden influx of players, a higher Min Servers value can be useful. This approach ensures sufficient ready servers to handle the initial player influx, while avoiding excessively large buffer sizes, which may not be necessary as player growth is expected to stabilize after the initial rush.

Buffer Size

The buffer size tells the fleet how many servers it needs to keep "Ready" so that game sessions can claim them immediately. Starting a new server may take 1 to 10 minutes, which is an unacceptable wait time for players. The DS creation time includes AMS initializing a new host instance, downloading the dedicated server image, and getting it to start and connect to the AMS Watchdog. (While bare metal servers do not need need to be initialized, they still require time for image download and startup.)

We recommend assuming 10 minutes as the DS creation time when determining how high to set your buffer size. If the buffer size is too small for how much demand is increasing, games will have to wait for servers.

注記

For development fleets, the buffer setting usually works best between 1 and the number of dedicated servers per VM.

• If set to 1, a new VM won't start until all existing VMs are full.
• If set to the same number as the dedicated servers per VM, a new VM starts as soon as any server on any existing VM is claimed.

In general, a new VM starts if there's not enough space on existing VMs for the number of DS in the buffer setting.

Estimating buffer size

Your required buffer size depends on how quickly demand changes and how long it takes to start a new server, according to this formula: buffer = <change in demand per unit time> x <max time to start a DS>.

Here's what the formula means:

• <change in demand per unit time> is the difference in the number of claimed servers at two points in time.
  • The formula used to determine this is (<demand at t2> - <demand at t1>)/(t2-t1). <demand at t1> and <demand at t2> are the expected numbers of claimed servers at the start and end of the period. -t1 and t2, respectively, are the start and end time of the period over which the increase of demand is calculated.
• <max time to start a DS> is the estimated maximum time it takes to start a new server (up to 10 minutes).

In live game productions, we find that the buffer requirement is predominantly determined by short-term (up to 10 minutes) fluctuations in the number of claimed servers rather than long-term (daily cycle) fluctuations. In other words, the trend in demand caused by a day-night cycle in a region becomes irrelevant compared to the changes in demand that occur within 1 to 10 minutes. This short-term variation is caused by several factors such as players leaving and entering matches. Considering the fact that an "In-Session" server that finishes one match has a short delay before it's replaced with a new "Ready" server, a buffer is required even if there is seemingly a stable demand. Because of this, we recommend to set the buffer size based on the short-term variation in demand, which we explain in Using Grafana metrics to estimate buffer size below. :::

For illustration, the following image shows how demand can change quickly, demonstrating the difference between long-term trends and short-term variations. You can see a sudden jump in the number of claimed servers. The buffer provides the "Ready" servers to handle this increase.

Using Grafana metrics to optimize fleet size

AMS provides Grafana dashboards that offer valuable insights into your fleet's performance. These dashboards help you make data-driven decisions when optimizing fleet size and scaling resources. For a comprehensive guide to these dashboards, refer to the AMS Dashboards documentation.

The AMS Fleet Overview dashboard provides detailed information for each region.

Use the dashboard information as follows:

• Namespace claim failure rate: If this shows any claim failures, it means players did not get a dedicated server. Check if you have sufficient "Ready" dedicated servers in that region. Also, consider if a claim was expected in that region, as in some cases it might indicate an incorrect session template. In the example above, the claim failure rate is 0, which is good.

• Running DS: Note the number of dedicated servers in the claimed state at any given time, and then assess whether your current buffer size is sufficient. Additionally, look for signs of wasted resources, such as consistently high numbers of ready servers. In that case, consider decreasing the buffer size.

• Buffer size recommendation: Get a better view of how much buffer is actually required over the past days for your fleets. Use the AMS Buffer Sizing dashboard, as described in the next section: Set buffer size based on live game data from Grafana.

Set buffer size based on live game data from Grafana

The AMS Buffer Sizing dashboard recommends a buffer size based on your game's historical data. When viewing this dashboard, you have the option to view the data of a specific fleet by providing its fleet_id. For more information about this dashboard, refer to the AMS Dashboards documentation.

The dashboard shows the required (labelled "recommended") buffer size for each region. It is the size of the buffer that would have been required based on the dedicated servers trend and short-term variation in claimed servers.

注記

• Initially, you may not have enough historical data to effectively use this dashboard. We recommend starting with a slightly larger buffer for the first one to two days. Then, adjust the buffer size on the dashboard data. You can also use the minimum setting during launch.
• Buffer requirements vary between games. We often see a buffers between 10% to 20% of the peak number of claimed DS (<peak CCU> / <players per server>). In some (rarer) scenarios, it can be as high as 50%. Use this as a starting point, but adjust based on the data.

To find a good buffer size, use the yellow line on the graph called Recommended buffer size setting (max over 24h). This line shows the biggest increase in claimed dedicated servers within 1 to 10 minutes over the past 24 hours of any short-term increase. Note its value over the past days to get an idea of the buffer requirement.

To get the best buffer size, we recommend choosing the highest number on this line over the last few days (13 dedicated servers in the example above). However, you must also consider if any recent event has affected the data in a way that makes the current data a less valid predictor for future demand. Find a balance between ensuring server availability and avoiding wasting resources. This means making sure players can easily play without having too many idle servers.

Best practices

• Monitor Usage: Regularly monitor your fleet's usage and adjust the maximum and buffer sizes as needed to optimize availability and cost.
• Monitor Claim Failures: Regularly check for claim failures on the AMS Dashboard in Grafana.
• Plan for Peaks: Consider historical data and expected player activity to set appropriate maximum and buffer sizes.

What's next

For more information on managing fleets and configuring other settings, refer to the Create fleets to deploy dedicated servers page.