# Customize a game session queue
This topic describes how to customize your game session queues to make the best possible decisions about game session placement. For more information about game session queues and how they work, see [Configure game session placement](queues-intro.md).
These Amazon GameLift Servers features require queues:
+ [Matchmaking with FlexMatch](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-tasks.html)
+ [Build a queue for Spot Instances](spot-tasks.md)
**Topics**
+ [Define a queue's scope](queues-design-scope.md)
+ [Build a multi-location queue](queues-design-multiregion.md)
+ [Evaluate queue metrics](queues-design-metrics.md)
# Define a queue's scope
Your game's player population might have groups of players who shouldn't play together. For example, if you publish your game in two languages each language should have its own game servers.
To set up game session placement for your player population, create a separate queue for each player segment. Scope each queue to place players into the correct game servers. Some common ways to scope queues include:
+ **By geographic locations.** When deploying your game servers in multiple geographic areas, you might build queues for players in each location to reduce player latency.
+ **By build or script variations.** If you have more than one variation of your game server, you might be supporting player groups that can't play in the same game sessions. For example, game server builds or scripts might support different languages or device types.
+ **By event types.** You might create a special queue to manage games for participants in tournaments or other special events.
## Design multiple queues
Depending on your game and players, you might want to create more than one game session queue. When your game client service requests a new game session, it specifies which game session queue to use. To help you determine whether to use multiple queues, consider:
+ Variations of your game server. You can create a separate queue for each variation of your game server. All fleets in a queue must deploy compatible game servers. This is because players who use the queue to join games must be able to play on any of the queue's game servers.
+ Different player groups. You can customize how Amazon GameLift Servers places game sessions based on player group. For example, you might need queues customized for certain game modes that require a special instance type or runtime configuration. Or, you might want a special queue to manage placements for a tournament or other event.
+ Game session queue metrics. You can set up queues based on how you want to collect game session placement metrics. For more information, see [Amazon GameLift Servers metrics for queues](monitoring-cloudwatch.md#gamelift-metrics-queue).
# Build a multi-location queue
We recommend a multi-location design for all queues. This design can improve placement speed and hosting resiliency. A multi-location design is required to use player latency data to put players into game sessions with minimal latency. If you're building multi-location queues that use Spot Instance fleets, follow the instructions in [Reduce game hosting costs with Spot fleets](fleets-spot.md).
One way to create a multi-location queue is to add a [multi-location fleet](gamelift-regions.md#gamelift-regions-hosting) to a queue. That way, the queue can place game sessions in any of the fleet's locations. You can also add other fleets with different configurations or home locations for redundancy. If you're using a multi-location Spot Instance fleet, follow best practices and include an On-Demand Instance fleet with the same locations.
The following example outlines the process of designing a basic multi-location queue. In this example, we use two fleets: one Spot Instance fleet and one On-Demand Instance fleet. Each fleet has the following AWS Regions for placement locations: `us-east-1`, `us-east-2`, `ca-central-1`, and `us-west-2`.
**To create a basic multi-location queue with multi-location fleets**
1. Choose a location to create the queue in. You can minimize request latency by placing the queue in a location near where you deployed the client service. In this example, we create the queue in `us-east-1`.
1. Create a new queue and add your multi-location fleets as queue destinations. The destination order determines how Amazon GameLift Servers places game sessions. In this example, we list the Spot Instance fleet first and the On-Demand Instance fleet second.
1. Define the queue's game session placement priority order. This order determines where the queue searches first for an available game server. In this example, we use the default priority order.
1. Define the location order. If you don't define the location order, Amazon GameLift Servers uses the locations in alphabetical order.
![\[A console screenshot that illustrates the example queue's locations and destination order.\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/images/queue-multi-location-1.png)
![\[A console screenshot that illustrates the example queue's placement priority and Location order.\]](http://docs.aws.amazon.com/gameliftservers/latest/developerguide/images/queue-multi-location-2.png)
# Evaluate queue metrics
Use metrics to evaluate how well your queues are performing. You can view metrics related to queues in the [Amazon GameLift Servers console](https://console.aws.amazon.com/gamelift) or in Amazon CloudWatch. For a list and descriptions of queue metrics, see [Amazon GameLift Servers metrics for queues](monitoring-cloudwatch.md#gamelift-metrics-queue).
Queue metrics can provide insight about the following:
+ **Overall queue performance** – Queue metrics indicate how successfully a queue responds to placement requests. These metrics can also help you identify when and why placements fail. For queues with manually scaled fleets, the `AverageWaitTime` and `QueueDepth` metrics can indicate when you should adjust capacity for a queue.
+ **FleetIQ algorithm performance** – For placement requests using the FleetIQ algorithm, metrics show how often the algorithm finds ideal game session placement. The placement may prioritize using resources with the lowest player latency or resources with the lowest cost. There are also error metrics that identify common reasons why Amazon GameLift Servers can't find an ideal placement. For more information about metrics, see [Monitor Amazon GameLift Servers with Amazon CloudWatch](monitoring-cloudwatch.md).
+ **Location specific placements** – For multi-location queues, metrics show successful placements by location. For queues that use the FleetIQ algorithm, this data provides useful insight into where player activity occurs.
When evaluating metrics for FleetIQ algorithm performance, consider the following tips:
+ To track the queue's rate of finding an ideal placement, use the `PlacementsSucceeded` metric in combination with the FleetIQ metrics for lowest latency and lowest price.
+ To boost a queue's rate of finding an ideal placement, review the following error metrics:
+ If the `FirstChoiceOutOfCapacity` is high, adjust capacity scaling for the queue's fleets.
+ If the `FirstChoiceNotViable` error metric is high, look at your Spot Instance fleets. Spot Instance fleets are considered not viable when the interruption rate for a particular instance type is too high. To resolve this issue, change the queue to use Spot Instance fleets with different instance types. We recommend that you include Spot Instance fleets with different instance types in each location.