U.S. Pat. No. 10,953,328

DYNAMIC BATCHING INTERVAL ADJUSTMENT FOR GAME SESSION CREATION

AssigneeAmazon Technologies Inc

Issue DateJune 3, 2019

Illustrative Figure

Abstract

A game-hosting service of a service provider network is configured to dynamically adjust a batching interval used to assign processes to game session requests in batches of processes. The adjustment of the batching interval may be based on a level of contention resulting from operations to assign processes to game session requests. With the batching interval adjusted, the game-hosting service may queue one or more incoming game session requests received during the batching interval, query a data store for available processes after a lapse of the batching interval, assign ones of the available server processes to the game session request(s), and instruct the assigned processes to host corresponding game sessions. Dynamically adjusting the batching interval in this manner allows high volume games to benefit from added throughput, while lower volume games can benefit from quicker latency.

Description

DETAILED DESCRIPTION Service providers offer various network-based (or “cloud-based”) services to users to fulfill computing needs of the users. These service providers may operate service provider networks that include clusters of managed servers stored in data centers located across different geographic regions. In this way, users who have subscribed for use of the network-based services (or “subscribers”) need not invest in and maintain the computing infrastructure required to implement the various services that they may need. Additionally, subscribers and their clients are able to access these network-based services over different geographic regions. To offer these network-based services across geographic areas, service providers operate and maintain service provider networks (e.g., cloud-based computing environments, network-based service architectures, network-based service infrastructures, etc.). In this way, service provider networks may provide subscribers with scalable, on-demand, and network-accessible computing platforms over large geographic regions such that the subscribers have readily-available VM instances at their disposal. These service provider networks allow subscribers to immediately have computing infrastructure over large geographic regions to fulfill individual computing needs of the subscriber, and also to provide computing resources to support services provided to clients of the subscribers. For example, a subscriber to the service provider network may be a game developer (e.g., individual, company, and/or other organization) that has developed an online game that they would like to provide to clients who desire to play the online game. However, the game developer may desire to provide access to their online game to clients over large geographic regions, and for large amounts of users. The amount of computing infrastructure (e.g., compute power, memory, storage networking, security, etc.) used to support and maintain an online gaming platform over different geographic regions that hosts game sessions for clients may be large enough to be impractical for game developers, particularly new or emerging ...

DETAILED DESCRIPTION

Service providers offer various network-based (or “cloud-based”) services to users to fulfill computing needs of the users. These service providers may operate service provider networks that include clusters of managed servers stored in data centers located across different geographic regions. In this way, users who have subscribed for use of the network-based services (or “subscribers”) need not invest in and maintain the computing infrastructure required to implement the various services that they may need. Additionally, subscribers and their clients are able to access these network-based services over different geographic regions. To offer these network-based services across geographic areas, service providers operate and maintain service provider networks (e.g., cloud-based computing environments, network-based service architectures, network-based service infrastructures, etc.). In this way, service provider networks may provide subscribers with scalable, on-demand, and network-accessible computing platforms over large geographic regions such that the subscribers have readily-available VM instances at their disposal. These service provider networks allow subscribers to immediately have computing infrastructure over large geographic regions to fulfill individual computing needs of the subscriber, and also to provide computing resources to support services provided to clients of the subscribers.

For example, a subscriber to the service provider network may be a game developer (e.g., individual, company, and/or other organization) that has developed an online game that they would like to provide to clients who desire to play the online game. However, the game developer may desire to provide access to their online game to clients over large geographic regions, and for large amounts of users. The amount of computing infrastructure (e.g., compute power, memory, storage networking, security, etc.) used to support and maintain an online gaming platform over different geographic regions that hosts game sessions for clients may be large enough to be impractical for game developers, particularly new or emerging game developers, to purchase and maintain on their own.

Accordingly, service provider networks may provide a game-hosting service that is a fully, or at least partially, managed online gaming platform. The game-hosting service may deploy, operate, and scale session-based online game servers in the service provider network on behalf of game developers. The game-hosting service may provide groups, or “fleets,” of virtual machine instances (e.g., VM instances, instances, etc.) that execute on computing resources of the service provider network and host game sessions for clients of a subscribing game developer. Game software included in a game build can be provisioned to a fleet of instances, and the game-hosting service may spin up the fleet of instances, where each instance in the fleet executes at least one process that is to host a game session. When clients of a game developer want to play a game that is hosted by a game-hosting service, the game-hosting service may be tasked with assigning server processes—which are to be used for hosting the server component of the game—to incoming game session requests. Because this assignment process is typically performed for each game session request upon receipt of the request, contention can arise between assignment operations, especially when the throughput of incoming game session requests increases. For example, when the game-hosting service starts receiving upwards of 50 to 100 game session requests per second, the competition for computing resources to host those game sessions inherently increases, which gives rise to contention in the form of assignment failures if the system is attempting to assign server processes to the incoming game session requests using a common pool of server processes. When this contention spikes, it can degrade the performance of the game-hosting service. Traditional approaches to dealing with this contention, such as sharding, help mitigate contention, but they come with a drawback of fragmenting the set of available processes.

This disclosure describes, among other things, techniques and systems implemented by a game-hosting service of a service provider network to dynamically adjust a batching interval used to assign processes to game session requests in batches of processes. Before processes are assigned to game sessions (or the corresponding game session requests), the processes execute in an idle mode on a fleet of the subscriber. The game-hosting service can utilize the batching interval to assign these idle processes to incoming game session requests in batches of processes. That is, the game-hosting service may queue one or more incoming game session requests received during the batching interval, and, after a lapse of the batching interval, may query a data store for a number of available processes to assign to the queued game session request(s). The game-hosting service may then assign ones of the available server processes to the game session request(s), and may instruct the assigned process(es) to host corresponding game session(s).

Adjustment of the batching interval may be based on a level of contention (as determined from collected contention data) resulting from operations to assign processes to game session requests. For example, the game-hosting service may periodically or continuously receive contention data relating to operations that are performed to assign processes to game session requests, and may determine, based at least in part on the contention data, a level of contention resulting from the assignment operations. In some embodiments, the level of contention is determined as a number or a percentage of failed attempts to assign processes to game session requests over a time period. This is because, when contention is high, competition for available processes is also high, which results in a relatively high number of failed attempts to assign processes to game session requests caused by those processes having been already assigned to another game session request. Based on the level of contention, the game-hosting service may adjust (e.g., increase or decrease) the batching interval to a new value (e.g., a period of time). The value of the batching interval defines the frequency at which a data store is queried for available processes that are to be assigned in batch to a queue of game session requests received during the previous batching interval.

Adjusting the batching interval up or down in this manner allows for accumulating a respectively larger or smaller set of game session requests in a queue before a set of processes are assigned, in batch, to the accumulated game session requests. In general, this batching approach increase efficiency of the assignment operations, as compared to individually querying the data store for each game session request in order to assign a process to that game session request. That is, because the number of operations involved in assigning a batch of processes to corresponding game session requests is reduced from many operations (e.g., when individual queries are submitted for each game session request) to a single operation, this has the effect of reducing the contention that would otherwise result from the assignment operations. Increasing the batching interval to a longer duration is, therefore, likely to decrease the level of contention, which may arise when there is an increase in game session request throughput coupled with a relatively short batching interval. This dynamic adjustment of the batching interval thereby allows high volume games to benefit from added throughput, while lower volume games can benefit from quicker latency, which would not be possible with a static (non-adjustable) batching interval.

An example process implemented by one or more computing devices of a game-hosting service for adjusting a batching interval may include determining a level of contention resulting from operations to assign processes to game session requests, and adjusting, based at least in part on the level of contention, a batching interval from a first period of time to a second period of time. With the batching interval adjusted, the process may further include queuing multiple game session requests received during the batching interval, and, after a lapse of the second period of time of the batching interval, querying a data store for a number of available processes that is greater than or equal to a number of the multiple game session requests. At least some of these available processes may then be assigned to the multiple game session requests as assigned processes, and the assigned processes may be executed to host game sessions that correspond to the game session requests.

By dynamically adjusting the batching interval—which is used to assign processes to game session requests in batches of processes, a game-hosting service can determine, based at least in part on observed contention resulting from the process-to-session assignment operations, when, and/or how fast, and/or by how much, to increase the batching interval for purposes of mitigating the observed contention. The game-hosting service can also determine when, and/or how fast, and/or by how much, to decrease the batching interval when the observed contention subsides. This helps provide a game-hosting service that maintains an acceptable performance level for clients that are playing games hosted by the game-hosting service. The performance level is maintained by dynamically adjusting the batching interval of the process-to-session assignment operations to mitigate contention, as needed. This mitigation of contention prevents computing resources from being overleveraged and thereby avoids degradation in the system's performance when hosting game sessions for subscribers and their clients.

While some of the techniques are described herein as being performed in a service provider network of a service provider, the techniques may similarly be applied in other computing networks, such as on-premise servers managed by the game developers themselves. Certain implementations and embodiments of the disclosure will now be described more fully below with reference to the accompanying figures, in which various aspects are shown. However, the various aspects may be implemented in many different forms and should not be construed as limited to the implementations set forth herein. The disclosure encompasses variations of the embodiments, as described herein. Like numbers refer to like elements throughout.

FIG. 1illustrates a system-architecture diagram of an example environment100in which a game-hosting service of a service provider network102can dynamically adjust a batching interval used to assign processes to game session requests in batches of processes.

As illustrated, the service provider network102may be operated and/or managed by a service provider104. The service provider network102may provide various services to users to fulfill their computing resource needs, such as cloud-based computing resources. For example, the service provider network102may provide cloud-based, scalable, and network accessible compute power services, storage services, database services, and/or other services. As illustrated, the service provider network102may also provide a game-hosting service106that is a scalable, cloud-based runtime environment for online games, including session-based multiplayer games. The game-hosting service106may be fully managed by the service provider104and deploy, operate, and scale the session-based multiplayer game servers in the cloud-based, or network-based, environment. For example, the game-hosting service106may not only provide the hardware to host the game sessions, but also manage ongoing activity, security, storage, and performance tracking. Additionally, the game-hosting service106may provide auto-scaling capabilities such that instances supporting game sessions can be spun up or spun down based on player demand.

To utilize the game-hosting service106, developers110may utilize developer devices108to register for an account (e.g., a user account, subscriber account, etc.) with the game-hosting service106. This may allow the developers110(sometimes referred to herein as “subscribers”110) to subscribe to the game-hosting service106, provide a game build(s) for their online game(s), and to provide their clients112with access to the online game(s) via their client devices114without the developers110having to invest in the computing resources (e.g., on-premise resources) needed to host the online game sessions for their clients112. In order to utilize the game-hosting service106, the developers110may provide a game build118to the game-hosting service106via one or more developer portals116. The developer portal(s)116may include one or more of a web-based console, a software-development kit (SDK), a command-line interface (CLI), an application programming interface (API), and/or any other means by which a developer110may specify and/or provide a game build118to the game-hosting service106.

The game build118may correspond to any type of online game that may host a game session for one or more clients112(sometimes referred to herein as “players”112). For instance, the game build118may correspond to a session-based single player online game, or a session-based multiplayer online game. The game build may represent any type of online game, such as real-time strategy (RTS) games, first person shooter (FPS) games, multiplayer online battle arena (MOBA) games, role playing (RPG) games, massively multiplayer online (MMO) games, massively multiplayer online role player games (MMORPG), virtual board games (e.g., chess, checkers, etc.), action-adventure games, simulation games, strategy games, sports games, virtual reality games, and/or any other game that may be played in an online environment.

Generally, the client devices114may comprise any type of computing device that may be utilized for online gaming. For instance, the client devices114may include laptop computing devices, desktop computing devices, mobile phones, gaming systems, controller-based devices, virtual and/or augmented reality devices (e.g., head-mounted displays (HMDs)), other wearable devices, biometric sensors, projectors, televisions, and/or any computing device usable on its own, or in conjunction with other devices, for online gaming. In some examples, at least part of the online game may execute and/or be stored locally on the client devices114.

The game build118may include the game software for the online game, and may further include server executables, supporting assets, libraries, and dependencies that are all used to host and/or execute the game software on an instance. The developers110may provide the game build118through the developer portal(s)116, such as by uploading the game build118over one or more networks120(e.g., the Internet, wireless wide area networks (WANs), personal area networks (PANs), wired and/or wireless local area networks (LANs), etc.). The network(s)120may comprise any type of network or combination of network, including wired and/or wireless networks. Once a developer110has uploaded their game build118, the game-hosting service106may deploy the game software130to one or more game servers124in a computing-resource network122. For instance, the game software130may be installed on one or more virtual machine (VM) instances126that are at least partially managed by a local agent128(e.g., script, program, application, etc.).

The computing-resource network122may include data centers that each include one or more computing resources, such as VM instances126(1) to126(N) where “N” is any integer greater than or equal to 2 (referred to herein collectively as “VM instances126” “or just “instances126”). The data centers may house the game server(s)124and may be located across disparate geographical regions such that computing resources are available to support functionality for cloud-based services provided by the service provider network102. The computing resources may include various combinations of hardware-based components, such as central processing units (CPU), graphics processing units (GPU), memory, storage, network capacity, security, and/or any other type of hardware-based resource to support cloud-based services, such as the game-hosting service106. In some examples, the computing resource network122may further include respective memories that store various firmware-based and/or software-based resources that provide the functionality of the services, such as the instances126on which an agent128executes, the game software130executes, and one or more processes132execute to support a game session.

Generally, the agent128may be responsible for handling various processes on an instance126, such as spinning up an instance126, spinning down an instance126, handling lifetime processes of the instance126, retrieving game session assignments for processes132executing on the instance126, executing processes132on the instance126to host a game session, managing resources of the instance126, installing patches and/or other software on the instance126and/or various other actions for managing the instance126. The data store134may, among other things, keep track of the processes132that are executing on VM instances126across subscribers'110fleets, and the ownership of those processes132in terms of whether they are available (e.g., executing in idle mode without an owner), or already assigned to a game session (or game session request).

In some examples, each process132(sometimes referred to as a “server process”132) that executes on an instance126may support a game session that engages one or more clients via their client device(s)114. That is, each process132may support one game session. For instance, the process(s)132may each be running the game software130to support a game session for one or more clients112. Often, a process132supports a game session for multiple clients112(e.g., as with a multi-player game). A game session is an instance of the game software130running on a server that clients112can connect to and interact with. The game defines the basic characteristics of the game session, such as the life span or the number of players involved. Although many of the examples described herein pertain to a single process132supporting a single game session, it is to be appreciated that, depending on the game (e.g., the size of the game, complexity of the game, the number of clients112engaged in a single game session, and/or other factors), a process132may handle multiple game sessions (e.g., for “lighter weight” mobile games), and/or perform other tasks besides hosting a game session to help manage game sessions, interact with client devices114and/or the game-hosting service106, manage the instance126, and/or perform other actions. The process(s)132may be binary processes132, executable processes132, etc., running on the VM instance126that consume or utilize the underlying hardware resources and/or other resources.

To play in a game session, the client devices114may interact directly with the game-hosting service106, and/or through various backend game services to retrieve information on current game sessions, to request new game sessions, and/or reserve slots in game sessions. For instance, the client devices114may interact, over one or more networks120, with game services138that may handle communication between client devices114and the game-hosting service106. Further, the game services138may handle additional tasks or provide additional services, such as player authentication and authorizations, team building and matchmaking, and inventory control. For example, when a client112wants to start a new game, the client device114may call the authentication service to first verify the client's112identity, and then send a game session request to the game-hosting service106.

In further examples, the online game of a developer110may rely on or utilize one or more additional external services140, such as for validating a subscription membership and/or determining entitlements for a client's account. As shown, the information from the external services140may be passed to the game server(s)124via the game services138and the game-hosting service106without going through the client device(s)114.

To establish or join a game session, clients112may utilize their client devices114(e.g., applications, software, or other programs executing thereon) to request (e.g., via an API call) that the game-hosting service106place them in a game session. To create a game session, a match is generally formed or made as an initial step, followed by a step of placing the match. In some embodiments, the game services138may execute matchmaking logic to match players112together in matches. For example, if a player112connects to the game services138over the network120for playing a multiplayer game, the client device114of the player112may present a screen that lists other online players112for selection, and the player112can select another player112from the list to play against. Other matchmaking factors can be considered as well, or as an alternative, such as skill level (e.g., match players112with commensurate skill levels). In some embodiments, the game-hosting service106may execute matchmaking logic on behalf of a game developer110.

After forming a match, the game-hosting service106may be tasked with placing the match. It is to be appreciated that, in some embodiments, short of forming a new match, the game-hosting service106may identify an already running process132that is hosting a game session, and if the active game session has an open player slot(s) that the player(s)112associated with the game session request can be placed into, the game-hosting service106may assign the player(s)112to the open player slot(s) in the active game session, without having to form a separate match. Otherwise, the game-hosting service106may have already spun up VM instances126in fleets that are allocated for various subscribers of the service provider network102, and each of the spun up VM instances126may have server processes132executing thereon in idle mode until the processes132are assigned to a game session request for hosting a corresponding game session (associated with a match) until the game session ends. Other than loading maps and other data for hosting a particular game session, these idle processes may be ready to start hosting a game session as soon as they are assigned to a game session request. The game-hosting service106may be tasked with identifying a server process132executing on a VM instance126that is executing on a common server124, which will serve multiple players112in a set (e.g., 2, 10, 100, etc.) of players112that have been matched together for playing a multi-player game. Accordingly, for an incoming game session request, the game-hosting service106may resolve a fleet alias by calling a routing service, load fleet data to determine a fleet of VM instances126associated with the incoming game session request, and query the data store134to identify available (e.g., idle) processes132that are usable to host a game session corresponding to the incoming game session request. It is to be appreciated that, for efficiency reasons, the game-hosting service106may “pack” server processes132as tight as possible to avoid overutilization of resources. That is, the game-hosting service106may try to minimize the number of processes132that are concurrently executing in idle mode in order to have available a sufficient number of processes132while also avoiding unnecessary computing resource consumption that could be utilized for other purposes.

A batching interval136can be used for assigning processes132to game session requests in batches of processes132. This batching interval136may be adjustable over a range of values (e.g., from 0 to TMAX, where TMAXrepresents any suitable value representing a period of time, which may be specified in any suitable unit of time (e.g., milliseconds, seconds, etc.)). The batching interval136may be adjustable to any value over (or within) the range of values. In an illustrative example, the range of values over which the batching interval136is adjustable may range from 0 seconds to about 5 seconds (e.g., TMAX=5 seconds). When the batching interval136is set to a non-zero (or positive) value, incoming game session requests that are received during a given batching interval136may be queued (e.g., placed in a queue), and, after a lapse of the batching interval136, the game-hosting service106may query142the data store134that keeps track of executing processes132for a set of available processes132that are idle, and, therefore, usable to host a game session. The game-hosting service106may query142the data store134for a number of available processes132that is greater than or equal to the number of game session requests that have been queued during the previous batching interval136. In an illustrative example, if the batching interval136is set to T1=100 milliseconds, incoming game session requests are queued over a 100-millisecond interval, and, after a lapse of the 100-millisecond interval, a number of game session requests may have been received and queued. Consider an example where 20 game session requests were received during the 100-millisecond interval. After a lapse of the batching interval136, the game-hosting service106may query142the data store134for a number of available processes132. The number of available processes132can be greater than or equal to the number of game session requests (e.g., by submitting a query142for 30 available processes132to assign to 20 game session requests). This ensures that there is a sufficient number of processes132to assign at least one process132to each game session request. Requesting a number of available processes132that is strictly greater than the number of game session requests provides a buffer (e.g., extra processes132), which may be useful in case of a failure to assign one or more of the available processes132. For example, if a process132has already been assigned to another game session request at a time when the process132is being assigned to a game session request, the assignment attempt may fail. Assignment attempts can fail for other reasons as well.

After receiving query results that include a number of available processes132, the game-hosting service106may assign at least some (e.g., a subset) of the available processes132to the game session requests that were queued over the previous batching interval136. In the running example, where the query results include 30 available processes132, the game-hosting service106may assign20of the 30 available processes132to the 20 game session requests. This assignment of processes132to game session requests may occur in various ways. In general, the game-hosting service106may select one of the game session requests and may traverse a list of the available processes132returned in the query results, one-by-one, attempting to assign the first process132in the list to the game session request, and if the assignment fails, running down the list, in order, until a process132in the list is successfully assigned to the game session request. This assignment process may iterate for each game session request until all game session requests are assigned at least one process132. The query results may return a list of available processes132ordered in any suitable manner. For example, the data store134may keep track of the “age” of executing processes132and, thus, may order query results based on age (e.g., from the oldest process132to the youngest process132, from the youngest process132to the oldest process132, etc.). In this manner, the game-hosting service106may scan the list of available processes132with a preference to assign processes132based on the age of the processes132by traversing the list from top-to-bottom. In some embodiments, available processes132in the data store134may be filtered on an age-related criterion (e.g., return available processes132that were created in the last N days, N being any suitable number) to generate query results that include a filtered set of processes132that satisfy the criterion.

The assignment of a process132to a game session request may utilize optimistic locking, meaning that a process132may not actually be locked when it is first accessed by a transaction (or operation) to assign the process132to a given game session request. This is why assignment failures can occur (e.g., if the process132has already been locked by another transaction/operation to assign the process132to another game session request). When the transactions per second (TPS) to assign processes132to game session requests is relatively high (e.g., 50 to 100 game session assignment TPS), contention can arise, and/or increase, in the form of an increased number or percentage of assignment failures caused by processes132already having been assigned to another game session request at a time of optimistic locking for a given game session request. Increasing the batching interval136can mitigate this contention by potentially increasing the number of game session requests that are associated with a single query142to the data store134, which means that there will not be any contention between assignment operations for at least the set of game session requests that are associated with the single query142. When contention subsides, the batching interval136can be decreased to a lower value to reduce the latency in assigning processes132to game session requests. The assignment of a process132to a game session request may further involve updating a record for the process132in the data store134with the new owner of the process132; namely, updating a process132record in the data store134with an identifier of the game session request (or a corresponding game session) to which the process132has been assigned. In this manner, the process132is locked, or made unavailable, and the process132cannot thereafter be assigned to another game session request until its associated game session ends.

After assigning a process132to a game session request, a corresponding game session is created, and the assigned process132executing on a VM instance126of the subscriber's fleet may be instructed to host (or support) the created game session for one or more clients112of the subscriber110that are associated with the game session. The client application(s) running on the client device(s)114associated with the game session may receive connection information (e.g., a port of a server124, an IP address, etc.), and may create a game connection(s)144by connecting directly, over the network(s)120, to the open game server124using a player session ID(s). The server process132may then accept the player ID(s) as a valid ID(s) and accepts, or rejects, the game connection(s)144. If connected, the player session is set to active and the client(s)112begins playing the game using their client device(s)114and the game connection144that is established between the game server124that has the instance126with the process132executing to host the selection game session. Once a game session has ended (e.g., clients112quit, the game ends, time out, etc.), the client application on each of the involved client devices114may disconnect from the process132, and the game-hosting service106can change the game session to terminated, upload a game session log to storage, and update a fleet utilization to indicate that the game server124has one less process executing132.

It is to be appreciated that the game-hosting service106may deploy (e.g., via a control plane) a fleet of hosts, and each host of the fleet of hosts may implement its own batching interval136independently from the other hosts. The number of hosts in the fleet of hosts is configurable. In some embodiments, the number of hosts in the fleet of hosts may range from about 6 hosts to 30 hosts, depending on various factors. When the game-hosting service106receives a game session request, the game session request may be routed to one of the hosts in the fleet of hosts. The host that receives the game session request may implement its own batching interval136independently from the other hosts. This “per-host” batching means that, in some cases, a first host (host A) of the fleet of hosts may receive a single game session request (request A) during its own batching interval136, and a second host (host B) of the fleet of hosts may receive a single game session request (request B) during its own batching interval136, and the two game session requests (requests A and B) might contend with each other for the same server process132. In some embodiments, the individual batching intervals136utilized by each host of the fleet of hosts may be staggered with respect to each other. For example, an instance of the start time of the batching interval136for host A may not occur simultaneously with the start time of the batching interval136for host B (e.g., the start times of the respective batching intervals may not be synchronized), and so on for any number of hosts in a fleet of hosts. Staggering the batching intervals136in this way can reduce contention, as compared to having multiple batching intervals136synchronized with each other.

As mentioned, the game-hosting service106may deploy a group of instances126, often referred to as a “fleet” of instances126, on game servers124. In various examples, a fleet of instances126may all support the same game build118, or the same online game. Each instance126in a fleet may run multiple processes132simultaneously, depending on the hardware capability, and each server process can host at least one game session. Since a game build118can have one or multiple executable files, a developer110and/or the service provider104may configure a fleet to run multiple server processes132of each executable on each instance126. In order to configure a fleet of instances126to run one or more processes132, the developer110and/or service provider104may generate configuration data146that describes what processes132run on each instance126in a fleet. Each instance126in the fleet launches the server processes132specified in the configuration data146and launches new ones as existing processes132end. Each instance126may regularly check for updated configuration data146and follows the new instructions.

FIG. 2illustrates a component diagram200of an example service provider network102that provides a game-hosting service106that is configured to dynamically adjust a batching interval136used to assign processes132to game session requests in batches of processes. As illustrated, the service provider network102may include one or more hardware processors202(processors) configured to execute one or more stored instructions. The processor(s)202may comprise one or more cores. Further, the service provider network102may include one or more network interfaces204configured to provide communications between the service provider network102and other devices, such as the developer device(s)108and/or the client device(s)114. The network interfaces204may include devices configured to couple to PANs, wired and wireless LANs, wired and wireless WANs, and so forth. For example, the network interfaces204may include devices compatible with Ethernet, Wi-Fi™, and so forth.

The service provider network102may also include computer-readable media206that stores various executable components (e.g., software-based components, firmware-based components, etc.). In addition to various components discussed inFIG. 1, the computer-readable-media206may further store components to implement functionality described herein. While not illustrated, the computer-readable media206may store one or more operating systems utilized to control the operation of the one or more devices that comprise the service provider network102. According to one embodiment, the operating system comprises the LINUX operating system. According to another embodiment, the operating system(s) comprise the WINDOWS® SERVER operating system from MICROSOFT Corporation of Redmond, Wash. According to further embodiments, the operating system(s) can comprise the UNIX operating system or one of its variants. It should be appreciated that other operating systems can also be utilized.

The computer-readable media206may store portions, or components, of the game-hosting service106described herein. For instance, the computer-readable media206may store the developer portal(s)116through which developer(s)110may provide their game builds118, and/or other input for managing their online games. Additionally, the computer-readable media206may store a user interface component208configured to provide portals, user interfaces, and/or other avenues through which clients112and/or subscribers110may interact with information (e.g., account settings) and/or the online games hosted by the game-hosting service106. In some embodiments, the user interface component208may notify clients112, via a user interface presented on their respective client devices114, about the possibility that they may experience a short delay to place their match due to the batching of server process132assignments.

The computer-readable media206may further store a matchmaking component210configured to, when executed by the processor(s)202, provide various matchmaking functionality for the game-hosting service106. Generally, the matchmaking component210may include a customizable rules engine that allows developers110to design how to match clients112(or players112) together based on player attributes and game modes that are appropriate for the online game. The matchmaking component210may further manage the details for forming player groups for game sessions, and placing the player groups into active or recently created/initiated game sessions. As mentioned, the game services138may include its own matchmaking logic. In some embodiments, some matchmaking is performed by the game services138, while additional matchmaking logic may be executed by the matchmaking component210of the service provider network102to augment the matchmaking process.

The computer-readable media206may further store a queueing component212configured to, when executed by the processor(s)202, manage queues for placing new game sessions with appropriate or available hosting resources (e.g., instances126) across fleets and/or geographic regions. Generally, the matchmaking component210builds on the queueing component212because, once a match is created, the matchmaking component210may hand or send the match details to a queue that is managed by the queueing component212. The queueing component212may then search for available hosting resources (e.g., available processes132) in the fleet of instances126and start a new game session for the players in the match. As mentioned a batching interval136may be utilized to assign server processes132to incoming game session requests in batches of processes132. Therefore, the queueing component212may be configured to queue game session requests for the duration of the batching interval136, and then query the data store134between successive batching intervals136to identify available processes132that can be assigned to the queued game session requests for each batching interval136. The data store134is shown as storing batching interval data214which may store the present value (e.g., period of time) to which the batching interval136is presently set. That is, the batching interval136can be adjusted to any value within a range of values, and the batching interval data214may indicate the value that is to be used by the queueing component212.

The computer-readable media206may further store a metric-collection component216configured to, when executed by the processor(s)202, collect contention data218and/or other metric values that are utilized to determine how, when, how fast, and/or by how much, to adjust the batching interval136. The metric-collection component216may be configured to periodically, continuously, etc., collect the contention data218, and provide the contention data218to a batching interval adjustment component220stored in the computer-readable media206. The batching interval adjustment component220may be configured to, when executed by the processor(s)202, and based at least in part on the contention data218, adjust the batching interval136(e.g., by updating the batching interval data214).

In addition to contention data218, or as an alternative, the metric-collection component216may collect throughput data indicative of the number of game session requests received by the game-hosting service106per unit time. For example, throughput data may indicate whether the game-hosting service106is receiving 10 game session requests per second, 100 game session requests per second, or some other throughput value. The batching interval adjustment component220may be configured to, based at least in part on this throughput data, adjust the batching interval136, such as by increasing the batching interval136when throughput is high, and decreasing the batching interval when throughput is low. In an illustrative example, if the game-hosting service106is receiving 1,000 game session requests per second, the batching interval136may be adjusted to 100 milliseconds, and when the throughput increases to 10,000 game session requests per second, the batching interval136may be increased to 250 milliseconds to alleviate contention that is likely to result from the increased throughput.

The computer-readable media206may further store a monitoring component222that, when executed by the processor(s)202, collects information for a game session and logs them in a storage location for a developer110. For instance, the monitoring component222may identify and collect metrics for game sessions hosted on an instance126, such as length of the game sessions, players involved, type of game, events occurring in the game, hardware utilization metrics, players leaving and/or entering the game, and/or various other metadata for a game session that may be of interest to a developer110.

The computer-readable media206may further store an auto-scaling component224that, when executed by the processor(s)202, scales up or down the number of instances126available to host game sessions or other processes132. For example, the auto-scaling component224may provide a fast, efficient, and accurate way to match fleet capacity to player usage. In some examples, the auto-scaling component224may track the fleet's hosting metrics and determine when to add or remove instances126based on a set of guidelines, called policies, that may be defined by the developer110. The auto-scaling component224can adjust capacity in response to changes in player demand to help ensure that the fleet of instances126has availability for new players without maintaining an excessive amount of idle resources.

To utilize the services provided by the service provider network102, clients112and developers110may register for an account with the service provider network102. For instance, clients112and developers110may utilize a device to interact with an identity and access management (IAM) component226that allows the clients112and developers110to create an account with the service provider network102. Generally, the IAM component226may enable the clients112and developers110to manage access to their cloud-based services and computing resources securely. Using the IAM component226, the developers110may manage their game builds118and/or fleets of instances126as described herein. Additionally, clients112may interact with their account to, for example, change settings for their gaming experience, management payments, and/or other functions.

The data store134(e.g., object storage) may represent one or more data stores that stores various data described herein at one or more locations in the service provider network102. The data store134may track processes132that are currently executing on VM instances126of the service provider network102. Records for these processes132may include additional data/metadata including, without limitation, an owner (e.g., whether the process is idle and available, or assigned to a game session (or game session request) as an owner), identifiers of VM instance126, fleet, subscriber110, etc. The data store134may further include the game builds118for developers110that include game software130and configuration data146, which may be updated at any suitable time by the developer110or otherwise, along with other data described herein. The data store134may further store the batching interval data214, the contention data218, queues228in which new player groups or game groups (i.e., game session requests) are queued before being placed into instances126(e.g., and assigned a process132executing thereon), user accounts230for the clients112and/or developers110, and subscriber parameter values232, which, as explained in further detail below, may dictate the batching interval data214for a given subscriber110.

The computer-readable media206may be used to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the service provider network102. In some examples, the operations performed by the service provider network102, and or any components included therein, may be supported by one or more server devices. Stated otherwise, some or all of the operations performed by the service-provider network102, and or any components included therein, may be performed by one or more computer devices operating in a cloud-based arrangement.

By way of example, and not limitation, computer-readable storage media206can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media includes, but is not limited to, RAM, ROM, erasable programmable ROM (“EPROM”), electrically-erasable programmable ROM (“EEPROM”), flash memory or other solid-state memory technology, compact disc ROM (“CD-ROM”), digital versatile disk (“DVD”), high definition DVD (“HD-DVD”), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory fashion. The implementation of the various components described herein is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as operations, structural devices, acts, or modules. These operations, structural devices, acts, and modules can be implemented in software, in firmware, in special purpose digital logic, and any combination thereof.

FIG. 3illustrates a schematic diagram300of an example technique, implemented by a game-hosting service106, for dynamically adjusting a batching interval136based on a level of contention resulting from operations to assign processes132to game session requests.

Initially, the batching interval136may be set to a first value, T1, which may represent a first period of time (e.g., 100 milliseconds). Using this batching interval136set to a value of T1, the game-hosting service106may cause VM instances126to be spun up and to execute associated processes132, at least some of which execute in idle mode so as to be available to host a new game session. Thus, multiple first server processes132may execute on a fleet of VM instances126. The fleet of instances126may be allocated to a particular subscriber110of the service provider network102and may be running on computing resources of the service provider network102. As incoming game session requests302are received by the game-hosting service106, the game-hosting service106may perform operations to assign the multiple first server processes132to the incoming game session requests302. Specifically, the number, P, of the incoming game session requests302(1)-(P), P being any number, received during a batching interval136set to a value of T1may be queued304in a queue228of multiple game session requests302(1)-(P). After a lapse of the batching interval136set to a value of T1, the game-hosting service106may query142the data store134for a number, Q, of the multiple first server processes132, where Q≥P. Query results306returned based on the query142may include a set of Q available processes132that, according to the data store134at the time of the query142, are available to assign to the game session requests302(1)-(P).

The game-hosting service106may assign308at least a subset of the available processes132to the multiple game session requests302(1)-(P), as described herein. For example, the game-hosting service106may traverse a list of the available processes132(e.g., from top-to-bottom) to assign a process132to each game session request302in the set of P game session requests302(1)-(P). The assignment308of processes132may include updating records310for the processes132(1)-(Q) in the data store134. As mentioned, the assignment308of processes132to game session requests302may use optimistic locking. As such, upon updating310a record for a process132to indicate the new owner (e.g., game session request302), the update may result in a failed attempt to assign the process132to the game session request132. This may be due to the updating310of the record being conditional upon the owner in the process record being set to “NULL,” indicating that the process132has not been locked or otherwise been made unavailable.

Thus, over time (e.g., over several batching intervals136) these operations are performed to assign processes132to game session requests, and the metric-collection component216may track contention data218as these assignment operations are performed. The contention data218may include a number of failed attempts to assign individual processes132to game session requests302. The contention data218may also include a number of successful attempt to assign individual processes132to game session requests302. In this manner, the game-hosting service106may determine, a level of contention312(e.g., “tracked contention level312” inFIG. 3) resulting from the operations to assign processes132to game session requests302over a time period. For example, the game-hosting service106may look back in the history of the collected contention data218to determine, for a given time period (e.g., a time period of one second), a number or a percentage of failed attempts to assign individual processes132to a game session request302, wherein the failed attempts are caused by the individual processes132having already been assigned to a game session request302. Thus, inFIG. 3, the level of contention312is indicated as a value within a range of 0% to 100%, meaning a range of 0% assignment failures to 100% assignment failures. If there are no assignment failures, meaning there is not a single instance, over the time period, where an attempt to assign a process132to a game session request302failed, the contention level312is determined as 0%, or non-existent. On the other hand, if every assignment attempt, over the time period, resulted in a failure to assign a process132to a game session request302, the contention level312is determined as 100%. In practice, the contention level312may, at times, be non-existent (e.g., 0%), or, when throughput of game session requests302increases, the contention level312may trend upwards, but may not reach 100%.FIG. 3illustrates an example where the contention level312might be roughly 40% (e.g., 40% of all assignment attempts over the time period were failed attempts to assign processes132to game session requests302, caused by those processes132having already been assigned to another game session request302).

It is to be appreciated that “smoothing” may be utilized in tracking contention. That is, the game-hosting service may determine the level of contention312as a number or percentage of failed assignment attempts over a time period that is of a relatively long duration, which may avoid reacting to short spikes of contention that could be tolerated for a very short period of time without increasing the batching interval136.

In some embodiments, a threshold314(or threshold level of contention314) may be utilized to determine when to adjust316the batching interval136. For example, as long as the level of contention312remains below the threshold314, the batching interval136may not be adjusted. In other words, some amount of contention may be tolerable, according to some embodiments. However, if and when the game-hosting service106determines that the level of contention312(e.g., the number or the percentage of failed assignment attempts) is greater than or equal to the threshold314, the batching interval adjustment component220may adjust316the batching interval136by increasing the batching interval136from a first value (e.g., T1, representing a first period of time) to a second value (e.g., T2, representing a second period of time greater than the first period of time, T1). For example, T2may represent a period of time equal to 200 milliseconds. By increasing the batching interval136in this manner, the contention resulting from the assignment operations in the future may be mitigated, and the contention level312may decrease, as a result. Thus, the contention level312can be monitored, and, as soon as the contention level312falls back below the threshold314, the batching interval adjustment component220, may cease to increase the batching interval136any further. If the batching interval136is increased to a highest value (e.g., TMAX) of the range of values over which the batching interval136is adjustable, this may be another condition for ceasing to increase the batching interval136any further.

It is to be appreciated that the batching interval data214may, in addition to specifying the value of the batching interval136, specify other values, such as a rate at which the batching interval136is to be increased when adjusted316, a rate at which the batching interval136is to be decreased when adjusted316(where the rate of increase may be the same as, or different than, the rate of decrease), the threshold314(i.e., threshold level of contention) used to trigger an adjustment316of the batching interval136, and/or the range of values over which the batching interval136is adjustable. This data214can be configured appropriate to control when, how fast, by how much, and/or the extent to which the batching interval136is adjusted based on the contention level312. In some embodiments, when the rate at which the batching interval136is to be increased or decreased may be specified as an incremental amount of change per adjustment of the batching interval136. For example, the rate at which the batching interval136is increased may be specified as “increase the batching interval136in increments of 100 milliseconds.” Accordingly, so long as the contention level312is greater than or equal to the threshold314, the batching interval136may be adjusted (or floated) upward in increments of 100 milliseconds, where an adjustment is made each time the contention level312is re-calculated and determined to be greater than or equal to the threshold314. This may be a similar process in the opposite direction, but the adjustment increments may be different, or the same, in the downward direction. For example, if the contention level312is less than the threshold314, the batching interval may be adjusted (or floated) downward in increments of, say, 200 milliseconds, towards a minimum value (e.g., 0 milliseconds). A more gradual rate of adjustment of the batching interval136in either direction may mitigate a “bouncing around” effect that may occur if the adjustment to the batching interval136is faster or made in larger increments. On the other hand, a faster adjustment, and/or adjustment in larger increments, may have the effect of mitigating contention quicker. Thus, a balanced approach may be taken such that the rate of adjustment, and/or the amount of each adjustment may be at a value that is likely to mitigate contention, but unlikely to settle at a drastically different value.

In some embodiments, the batching interval adjustment component220may determine a target value for the batching interval136based at least in part on the level of contention312. For example, if the contention level312is relatively high, the relatively high target value may be determined, and the batching interval136may be adjusted immediately, or incrementally, towards the target value. By contrast, if the level of contention312is relatively low, a correspondingly lower target value may be determined, and the batching interval136may be adjusted immediately, or incrementally, towards the target value. This may be based on the notion that a relatively shorter batching interval136may be sufficient to mitigate a low-to-moderate level of contention312. The determination of a target value may be based on heuristics, machine learning algorithms, or the like. An example objective may be to keep the batching interval136as short as possible while still keeping the contention level312at an acceptable level (e.g., below the threshold314).

FIG. 4illustrates an example graphical user interfaces400by which a game developer110can adjust a parameter that controls an aspect of assigning processes132to game session requests302in batches of processes132. The developer110may have created a developer profile or account230with the service provider network102and may access the user interface400via a developer portal116.

The developer user interface400may include a message portion402that explains that a batching approach is being taken to assign server processes132to game session requests302in batches of server processes132. The message portion402may further explain a parameter that is adjustable via a control element404(e.g., a slider bar) to control an aspect of assigning processes132to game session requests302in batches of processes132. In the example user interface400FIG. 4, the developer110may adjust a parameter by manipulating the control element404, such as by moving a slider between leftmost end and a rightmost end of the control element404in the form of a slider bar. For instance, if the developer110manipulates the control element404by moving the slider all the way to the leftmost end of the slider bar, that means that the developer110is agreeing to have the game-hosting service106utilize a suitable batching interval136to try and maintain the contention level312at as low a level as possible (e.g., roughly 0% assignment failures). That is, if the developer110does not want to have any contention on its fleet(s) of VM instances126during game session placement, the batching interval136may be increased, as needed, to alleviate contention and bring the level of contention312as close to zero as possible. This may mean that the developer's110clients112may experience a short delay before their match is placed. On the other hand, if the developer110would like to minimize the use of the batching approach, the developer110can manipulate the control element404by moving the slider all the way to the rightmost end of the slider bar, which means that the system may minimize its utilization of the batching interval136, such as by keeping the batching interval136at a value of zero (0) seconds, and increasing the batching interval136by as little of an amount possible, and as seldom as possible. When the developer110manipulates the control element404, the user interface component208may update a subscriber parameter value232, and the user interface component208may configure the batching interval data214based on the updated subscriber parameter value232. For example, the user interface component208may set a value corresponding to a first rate at which the batching interval136is increased based on an increased level of contention312. The user interface component208may additionally, or alternatively, set a value corresponding to a second rate at which the batching interval136is decreased based on a decreased level of contention312. The user interface component208may additionally, or alternatively, set a value corresponding to the threshold314(e.g., threshold level of contention314) that triggers adjustment of the batching interval136. The user interface component208may additionally, or alternatively, set upper and lower values corresponding to a range over which the batching interval136is adjustable.

The processes described herein are illustrated as a collection of blocks in a logical flow graph, which represent a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described blocks can be combined in any order and/or in parallel to implement the processes.

FIG. 5illustrates a flow diagram of an example process500for dynamically adjusting a batching interval136based on a level of contention312resulting from operations to assign processes132to game session requests302. For discussion purposes, the process500is described with reference to the previous figures.

At502, a game-hosting service106(or a component thereof) may perform operations to assign processes132to game session requests302using a batching interval136set to a current value. It is to be appreciated that these processes132may be executing (e.g., in idle mode) on a fleet of VM instances126at a time of the assigning at block502. This fleet of VM instances126may be allocated to a subscriber110of a service provider network102, and the VM instances126, and the processes132executing thereon, may be running on computing resources of the service provider network102. The assigning of processes132to game session requests302at block502may involve queuing incoming game session requests302received during the batching interval136, and, after a lapse of the batching interval136, querying a data store134for a number of available processes132to assign to the queued game session requests302. Once assigned, these processes132may be executed on corresponding servers124to host corresponding game sessions.

At504, the metric-collection component216of the game-hosting service106may collect contention data218based at least in part on the assignment operations performed at block502. The contention data218may include a number (or count) of failed attempts to assign individual processes132to game session requests302. The contention data218may also include a number (or count) of successful attempt to assign individual processes132to game session requests302. The collection of contention data218at block504may occur periodically, continuously, or upon the occurrence of an event(s) (e.g., at the lapse of each batching interval136).

At506, the game-hosting service106(or a component thereof) may determining a level of contention312resulting from the operations to assign processes132to game session requests302. In other words, the level of contention312may be determined based at least in part on the contention data218collected at block504. For example, the game-hosting service106may look back in the history of the collected contention data218to determine (or detect), for a given time period (e.g., a time period of one second, one minute, etc.), a number of failed attempts to assign individual processes132to a game session request302, wherein the failed attempts are caused by the individual processes132having already been assigned to a game session request302, and wherein the failed attempts are indicative of contention resulting from the assignment operations performed at block502. As another example, the game-hosting service106may determine (or detect), for a given time period, a percentage of total attempts to assign individual processes132to game session requests302that correspond to failed attempts.

At508, the game-hosting service106(or a component thereof) may determine whether the level of contention312determined at block506violates a first (e.g., upper) threshold level of contention314. For example, the first (e.g., upper) threshold314may be violated at block508if the level of contention312is greater than or equal to the first threshold level of contention314(e.g., the number or the percentage of the failed attempts is greater than or equal to the first threshold314). As another example, the first (e.g., upper) threshold314may be violated at block508if the level of contention312is greater (e.g., strictly greater than) than the first threshold level of contention314(e.g., the number or the percentage of the failed attempts is greater than or equal to the first threshold314). Based on the first (e.g., upper) threshold314being violated at block508, the process500may follow the “YES” route from block508to block510.

At510, the game-hosting service106(or a component thereof) may determine whether a maximum (or highest) value of a range of values over which the batching interval136is adjustable has been reached. For example, on a previous iteration of the process500, the batching interval136may have been increased to a maximum value (e.g., TMAX, representing a period of time that is the highest value in the range). In this case, the process500may follow the “YES” route from block510back to block502, without increasing the batching interval136. That is, based at least in part on the batching interval136being set to a highest value in a range of possible values, the batching interval adjustment component220may cease to increase, or otherwise refrain from increasing, the batching interval136. If, at510, the maximum (or highest) value of the range of possible values for the batching interval136has not been reached, the process500may follow the “NO” route from block510to block512.

At512, the batching interval adjustment component220may adjust, based at least in part on the level of contention312, the batching interval136from a first period of time (a first value) to a second period of time (a second value). Specifically, at block512, the adjustment may include increasing the batching interval136to a new value that is greater than the existing value.

At sub-block514, the increasing at block512may include incrementing the batching interval136. For example, if an increase from a first period of time (a first value) to a second period of time (a second value) is to occur over multiple iterations of the process500, the batching interval512may be incremented from a first period of time (a first value) to an intermediate period of time (an intermediate value) greater than the first period of time, and then to a second period of time (a second value) greater than the intermediate period of time. The amount by which the batching interval136is incremented at block514may be determined based at least in part on the level of contention312determined at block506and/or the amount by which the level of contention312exceeds the first (e.g., upper) threshold314at block508. For example, if the level of contention312is relatively high, and/or the first (e.g., upper) threshold314is exceeded by a relatively high amount, the amount by which the batching interval136is incremented may be a relatively large increment, as compared to relatively lower levels of contention and/or a first (e.g., upper) threshold314that is exceeded by a small amount.

At sub-block516, the increasing at block512may include determining a target value to which the batching interval136is to be increased. The target value to which the batching interval136is to be increased at block516may be determined based at least in part on the level of contention312determined at block506and/or the amount by which the level of contention312exceeds the first (e.g., upper) threshold314at block508. For example, if the level of contention312is relatively high, and/or the first (e.g., upper) threshold314is exceeded by a relatively high amount, a relatively higher target value may be determined at sub-block516in order to alleviate contention quicker, as compared to relatively lower levels of contention and/or a first (e.g., upper) threshold314that is exceeded by a small amount. Furthermore, the batching interval136may be incremented towards the target value at sub-block514such that the target value is reached over multiple iterations of the process500.

It can be appreciated that, by iterating the process500, the batching interval136can be increased (e.g., incremented), and, on each iteration of block508, a determination can be made as to whether the level of contention312no longer violates (e.g., has fallen below) the first (e.g., upper) threshold314. As soon as the level of contention312is determined to be no longer violating the first (e.g., upper) threshold314, the batching interval adjustment component220may cease to increase the batching interval136.

Returning to with reference to block508, the determination at block508may be, on an initial iteration or any subsequent iteration of the process500, that the level of contention312does not violate the first (e.g., upper) threshold level of contention314(e.g., the number or the percentage of the failed attempts is less than the first (e.g., upper) threshold314). For example, the first (e.g., upper) threshold314may not be violated at block508if the level of contention312is less than or equal to the first threshold level of contention314(e.g., the number or the percentage of the failed attempts is greater than or equal to the first threshold314). As another example, the first (e.g., upper) threshold314may not be violated at block508if the level of contention312is less than (e.g., strictly less than) the first threshold level of contention314(e.g., the number or the percentage of the failed attempts is greater than or equal to the first threshold314). Based on the first (e.g., upper) threshold314not being violated at block508, the process500may follow the “NO” route from block508to block518.

At517, the game-hosting service106(or a component thereof) may determine whether the level of contention312determined at block506violates a second (e.g., lower) threshold level of contention. For example, the second (e.g., lower) threshold may not be violated at block517if the level of contention312is greater than or equal to the second threshold level of contention (e.g., the number or the percentage of the failed attempts is greater than the second threshold). As another example, the second (e.g., lower) threshold may not be violated at block517if the level of contention312is greater than (e.g., strictly greater than) the second threshold level of contention (e.g., the number or the percentage of the failed attempts is greater than the second threshold). Based on the level of contention312not violating the second (e.g., lower) threshold at block517, the process500may follow the “NO” route from block517back to block502, where the process500can iterate. Thus, if the level of contention312does not violate either of the first (e.g., upper) or the second (e.g., lower) thresholds, no adjustment to the batching interval136is made.

The determination at block517may be, on an initial iteration or any subsequent iteration of the process500, that the level of contention312violates the second (e.g., lower) threshold level of contention (e.g., the number or the percentage of the failed attempts is less than or equal to the second (e.g., lower) threshold). For example, the second (e.g., lower) threshold may be violated at block517if the level of contention312is less than or equal to the second threshold level of contention (e.g., the number or the percentage of the failed attempts is greater than the second threshold). As another example, the second (e.g., lower) threshold may be violated at block517if the level of contention312is less than (e.g., strictly less than) the second threshold level of contention (e.g., the number or the percentage of the failed attempts is greater than the second threshold). Based on the second (e.g., lower) threshold being violated at block517, the process500may follow the “YES” route from block517to block518.

At518, the game-hosting service106(or a component thereof) may determine whether a minimum (or lowest) value of a range of values over which the batching interval136is adjustable has been reached. For example, at startup, or on a previous iteration of the process500, the batching interval136may have been set to, or decreased to, a minimum value (e.g., 0, representing a period of zero seconds, which may be the lowest value in the range). In this case, the process500may follow the “YES” route from block518back to block502, without decreasing the batching interval136. That is, based at least in part on the batching interval136being set to a lowest value in a range of possible values, the batching interval adjustment component220may cease to decrease, or otherwise refrain from decreasing, the batching interval136. If, at518, the minimum (or lowest) value of the range of possible values for the batching interval136has not been reached, the process500may follow the “NO” route from block518to block520.

At520, the batching interval adjustment component220may adjust, based at least in part on the level of contention312, the batching interval136from a first period of time (a first value) to a second period of time (a second value). Specifically, at block520, the adjustment may include decreasing the batching interval136to a new value that is less than the existing value.

At sub-block522, the decreasing at block520may include decrementing the batching interval136. For example, if a decrease from a first period of time (a first value) to a second period of time (a second value) is to occur over multiple iterations of the process500, the batching interval512may be decremented from a first period of time (a first value) to an intermediate period of time (an intermediate value) less than the first period of time, and then to a second period of time (a second value) less than the intermediate period of time. The amount by which the batching interval136is decremented at block522may be determined based at least in part on the level of contention312determined at block506and/or the amount by which the level of contention312is less than the second (e.g., lower) threshold at block517. For example, if the level of contention312is relatively low, and/or the level of contention312is relatively far below the second (e.g., lower) threshold, the amount by which the batching interval136is decremented may be a relatively large decrement, as compared to relatively higher levels of contention and/or a level of contention312that is less than a second (e.g., lower) threshold by a small amount.

At sub-block524, the decreasing at block520may include determining a target value to which the batching interval136is to be decreased. The target value to which the batching interval136is to be decreased at block524may be determined based at least in part on the level of contention312determined at block506and/or the amount by which the level of contention312is less than the second (e.g., lower) threshold at block517. For example, if the level of contention312is relatively low, and/or the level of contention312is relatively far below the second (e.g., lower) threshold, a relatively lower target value may be determined at sub-block524in order to minimize latency during game session placement quicker, as compared to relatively higher levels of contention and/or a level of contention312that is less than a second (e.g., lower) threshold by a small amount. Furthermore, the batching interval136may be decremented towards the target value at sub-block524such that the target value is reached over multiple iterations of the process500.

Accordingly, it can be appreciated that the process500may iterate to adjust (e.g., increase or decrease) the batching interval136based at least in part on a level of contention312resulting from assignment operations that are performed to assign processes132to game session requests302. Furthermore, the batching interval136may be adjusted incrementally over a time period by iterating the process500.

FIG. 6illustrates a flow diagram of an example process600for assigning processes132to game session requests302using an adjustable batching interval136. For discussion purposes, the process600is described with reference to the previous figures.

At602, a queuing component212of the game-hosting service106may queue multiple game session requests302received during the batching interval136. These multiple game session requests may, for example, include at least a first game session request302(1) and a second game session request302(2), and perhaps additional game session requests302, depending on the throughput of game session requests at the given moment. The batching interval136may be set to any suitable value, for example, by using the process500, or as otherwise described herein.

At604, the queueing component212may determine that the batching interval136has lapsed. This means that it is time for the queuing component212to identify available server processes132that can be assigned in batch to the set of game session requests302queued during the batching interval136at block602.

At606, after a lapse of the batching interval136, the queuing component212may determine (e.g., by querying a data store134for) a number, Q, of available processes132that is greater than or equal to a number, P, of the multiple game session requests that were queued during the batching interval136at block602.

At608, the game-hosting service106(or a component thereof) may assign, from the available processes132, at least a subset of the available processes132to the multiple game session requests302. For example, a first process132(1) may be assigned to the first game session request302(1) and a second process132(2) may be assigned to the second game session request302(2).

At610, the assigned processes132may be instructed to host corresponding game sessions for the multiple game session requests302. For example, the first process132(1) may be instructed to host (or support) a first game session corresponding to the first game session request302(1), and the second process132(2) may be instructed to host (or support) a second game session corresponding to the second game session request302(2). Although contention can arise during the process600, the adjustability of the batching interval136(e.g., using the process500ofFIG. 5, or otherwise described herein), allows for increasing the batching interval136, as needed to mitigate contention, while decreasing the batching interval136at times when contention has subsided. In this manner, a game-hosting service106implementing the process600with a dynamically varying batching interval136may queue game session requests at block602for a longer batching interval136on one iteration, while queueing game session requests at block602for a shorter batching interval136on a subsequent iteration, or vice versa.

FIG. 7a flow diagram of an example process700for controlling an aspect of assigning processes132to game session requests302based on a selected parameter value404received via a developer user interface400.

At702, a user interface component208of a game-hosting service106may receive, via a user interface400presented on a computing device108of the subscriber110to a service provider network102, user input to adjust a parameter to a value (e.g., a subscriber parameter value232). This parameter value232, as described with reference toFIG. 4, may comprise a parameter value404indicative of a level of contention allowed during game session placements, or a parameter value404indicative of an amount of delay allowed during the game session placements. The user input may be received as a manipulation of the control element404(e.g., a slider bar) shown inFIG. 4. In other words, a developer110(or subscriber110) may dictate, through the adjustment of control element404exposed via a user interface400, whether and/or how much, they would like server process132assignments to be assigned in batch to game session requests302for their clients112. A given subscriber110may prefer little-to-no contention (e.g., higher throughput) during game session placement at the possible cost of some observable latency when clients112of the subscriber110are waiting for their match to be placed and the game session to start. Another subscriber110may prefer little-to-no latency during game session placement at the possible cost of some game session requests that timeout, if and when contention rises to a level that causes requests to timeout. Another subscriber110may prefer a balance between the two extremes.

At704, the user interface component208of the game-hosting service106may set, based at least in part on the value of the parameter232, one or more values that control an aspect of the server process132assignments using a batching interval136. For example, one or more values can be set (or changed) in the batching interval data214stored in the data store134based at least in part on the selected parameter value404.

At sub-block706, for example, a value may be set that corresponds to a first rate at which the batching interval136is, or is to be, increased based on an increase in a level of contention312. That is, the rate at which the batching interval136is to be increased may be set to a relatively faster rate or a relatively slower rate, depending on the selected parameter value404.

At sub-block708, for example, a value may be set that corresponds to a second rate at which the batching interval136is, or is to be, decreased based on a decrease in a level of contention312. That is, the rate at which the batching interval136is to be decreased may be set to a relatively faster rate or a relatively slower rate, depending on the selected parameter value404.

At sub-block710, for example, a value(s) may be set that corresponds to a threshold level(s) of contention, such as the first (e.g., upper) threshold314and/or the second (e.g., lower) threshold, that triggers adjustment of the batching interval136. That is, the threshold(s) used to trigger adjustment of the batching interval136may be set to a relatively higher threshold(s) or a relatively lower threshold(s), depending on the selected parameter value404.

At sub-block712, for example, upper and/or lower values may be set that correspond to, or define, a range over which the batching interval136is adjustable. That is, the upper value that represents a maximum (or highest) value the batching interval136may be adjusted to can be set to a relatively higher value or a relatively lower value, depending on the selected parameter value404.

FIG. 8is a system and network diagram that shows an illustrative operating environment that includes a service provider network102that can be configured to implement aspects of the functionality described herein. The service provider network102can provide computing resources, like VM instances and storage, on a permanent or an as-needed basis. Among other types of functionality, the computing resources122provided by the service provider network102may be utilized to implement the various services described above. As also discussed above, the computing resources provided by the service provider network102can include various types of computing resources, such as data processing resources like VM instances, data storage resources, networking resources, data communication resources, network services, and the like.

Each type of computing resource provided by the service provider network102can be general-purpose or can be available in a number of specific configurations. For example, data processing resources can be available as physical computers or VM instances in a number of different configurations. The VM instances can be configured to execute applications, including web servers, application servers, media servers, database servers, gaming applications, some or all of the network services described above, and/or other types of programs. Data storage resources can include file storage devices, block storage devices, and the like. The service provider network102can also be configured to provide other types of computing resources not mentioned specifically herein.

The computing resources provided by the service provider network102may be enabled in one embodiment by one or more data centers804A-804N (which might be referred to herein singularly as “a data center804” or in the plural as “the data centers804”). The data centers804are facilities utilized to house and operate computer systems and associated components. The data centers804typically include redundant and backup power, communications, cooling, and security systems. The data centers804can also be located in geographically disparate locations, or regions806. One illustrative embodiment for a data center804that can be utilized to implement the technologies disclosed herein will be described below with regard toFIG. 9.

The clients110and developers110that utilize the service provider network102may access the computing resources provided by the service provider network102over any wired and/or wireless network(s)120, which can be a wide area communication network (“WAN”), such as the Internet, an intranet or an Internet service provider (“ISP”) network or a combination of such networks. For example, and without limitation, a client device114operated by a client112of the service provider network102may be utilized to access the service provider network102by way of the network(s)120. It should be appreciated that a local-area network (“LAN”), the Internet, or any other networking topology known in the art that connects the data centers804to remote clients and other users can be utilized. It should also be appreciated that combinations of such networks can also be utilized.

As illustrated, as game session requests302associated with clients112are received, a metric-collection component216may collect contention data218and/or other metric values that are utilized to determine how, when, how fast, and/or by how much, to adjust the batching interval136that is utilized for assigning processes132to game session requests302. The metric-collection component216may be configured to periodically, continuously, etc., collect the contention data218and provide the contention data218to a batching interval adjustment component220. The batching interval adjustment component220may be configured to, based at least in part on the contention data218, adjust the batching interval136(e.g., by updating batching interval data214) so that the assignment of processes132to game session requests302occurs at the updated/adjusted batching interval136.

FIG. 9is a computing system diagram900that illustrates one configuration for a data center804that implements aspects of the technologies disclosed herein. The example data center804shown inFIG. 9includes several server computers902A-902F (which might be referred to herein singularly as “a server computer902” or in the plural as “the server computers902”) for providing computing resources904A-904E. In some examples, the resources904and/or server computers902may include, be included in, or correspond to, the computing resource network122described herein.

The server computers902can be standard tower, rack-mount, or blade server computers configured appropriately for providing the computing resources described herein (illustrated inFIG. 9as the computing resources904A-904E). As mentioned above, the computing resources provided by the service provider network102can be data processing resources such as VM instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, networking resources, and others. Some of the servers902can also be configured to execute a resource manager906capable of instantiating and/or managing the computing resources. In the case of VM instances, for example, the resource manager906can be a hypervisor or another type of program configured to enable the execution of multiple VM instances on a single server computer902. Server computers902in the data center804can also be configured to provide network services and other types of services.

In the example data center804shown inFIG. 9, an appropriate LAN908is also utilized to interconnect the server computers902A-902F. It should be appreciated that the configuration and network topology described herein has been greatly simplified and that many more computing systems, software components, networks, and networking devices can be utilized to interconnect the various computing systems disclosed herein and to provide the functionality described above. Appropriate load balancing devices or other types of network infrastructure components can also be utilized for balancing a load between each of the data centers804A-804N, between each of the server computers902A-902F in each data center804, and, potentially, between computing resources in each of the server computers902. It should be appreciated that the configuration of the data center804described with reference toFIG. 9is merely illustrative and that other implementations can be utilized.

The data center804shown inFIG. 9also includes a server computer902F that can execute some or all of the software components described above. For example, and without limitation, the server computer902F (and the other server computers902) can generally correspond to a server configured to execute components of the game-hosting service106including, without limitation, the metric-collection component216and the batching interval adjustment component220, and/or the other software components described above. The server computer902F can also be configured to execute other components and/or to store data for providing some or all of the functionality described herein. In this regard, it should be appreciated that the services illustrated inFIG. 9as executing on the server computer902F can execute on many other physical or virtual servers in the data centers904in various embodiments. Thus, the data center804inFIG. 9may also include a plurality of server computers902that execute a fleet of VM instances126, which are executing processes to host game sessions for online games.

FIG. 10shows an example computer architecture for a computer1000capable of executing program components for implementing the functionality described above. The computer architecture shown inFIG. 10illustrates a server computer, workstation, desktop computer, laptop, tablet, network appliance, e-reader, smartphone, or other computing device, and can be utilized to execute any of the software components presented herein. In some examples, the server computer1000may correspond to one or more computing devices that implements the game-hosting service106described inFIG. 1.

The computer1000includes a baseboard1002, or “motherboard,” which is a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units (“CPUs”)1004operate in conjunction with a chipset1006. The CPUs1004can be standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computer1000.

The CPUs1004perform operations by transitioning from one discrete, physical state to the next through the manipulation of switching elements that differentiate between and change these states. Switching elements generally include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide an output state based on the logical combination of the states of one or more other switching elements, such as logic gates. These basic switching elements can be combined to create more complex logic circuits, including registers, adders-subtractors, arithmetic logic units, floating-point units, and the like.

The chipset1006provides an interface between the CPUs1004and the remainder of the components and devices on the baseboard1002. The chipset1006can provide an interface to a RAM1008, used as the main memory in the computer1000. The chipset1006can further provide an interface to a computer-readable storage medium such as a read-only memory (“ROM”)1010or non-volatile RAM (“NVRAM”) for storing basic routines that help to startup the computer1000and to transfer information between the various components and devices. The ROM1010or NVRAM can also store other software components necessary for the operation of the computer1000in accordance with the configurations described herein.

The computer1000can operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as the network908. The chipset1006can include functionality for providing network connectivity through a NIC1012, such as a gigabit Ethernet adapter. The NIC1012is capable of connecting the computer1000to other computing devices over the network908(or120). It should be appreciated that multiple NICs1012can be present in the computer1000, connecting the computer to other types of networks and remote computer systems.

The computer1000can be connected to a mass storage device1018that provides non-volatile storage for the computer. The mass storage device1018can store an operating system1020, programs1022(e.g., the game-hosting service106and sub-components thereof, including, without limitation, a metric-collection component216and a batching interval adjustment component220), and data, which have been described in greater detail herein. The mass storage device1018can be connected to the computer1000through a storage controller1014connected to the chipset1006. The mass storage device1018can consist of one or more physical storage units. The storage controller1014can interface with the physical storage units through a serial attached SCSI (“SAS”) interface, a serial advanced technology attachment (“SATA”) interface, a fiber channel (“FC”) interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.

The computer1000can store data on the mass storage device1018by transforming the physical state of the physical storage units to reflect the information being stored. The specific transformation of physical state can depend on various factors, in different embodiments of this description. Examples of such factors can include, but are not limited to, the technology used to implement the physical storage units, whether the mass storage device1018is characterized as primary or secondary storage, and the like.

For example, the computer1000can store information to the mass storage device1018by issuing instructions through the storage controller1014to alter the magnetic characteristics of a particular location within a magnetic disk drive unit, the reflective or refractive characteristics of a particular location in an optical storage unit, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this description. The computer1000can further read information from the mass storage device1018by detecting the physical states or characteristics of one or more particular locations within the physical storage units.

In addition to the mass storage device1018described above, the computer1000can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the computer1000. In some examples, the operations performed by the network-based service platform102, and or any components included therein, may be supported by one or more devices similar to computer1000. Stated otherwise, some or all of the operations performed by the service provider network102, and or any components included therein, may be performed by one or more computer devices1000operating in a network-based arrangement.

By way of example, and not limitation, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media includes, but is not limited to, RAM, ROM, erasable programmable ROM (“EPROM”), electrically-erasable programmable ROM (“EEPROM”), flash memory or other solid-state memory technology, compact disc ROM (“CD-ROM”), digital versatile disk (“DVD”), high definition DVD (“HD-DVD”), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory fashion.

As mentioned briefly above, the mass storage device1018can store an operating system1020utilized to control the operation of the computer1000. According to one embodiment, the operating system comprises the LINUX operating system. According to another embodiment, the operating system comprises the WINDOWS® SERVER operating system from MICROSOFT Corporation of Redmond, Wash. According to further embodiments, the operating system can comprise the UNIX operating system or one of its variants. It should be appreciated that other operating systems can also be utilized. The mass storage device1018can store other system or application programs and data utilized by the computer1000.

In one embodiment, the mass storage device1018or other computer-readable storage media is encoded with computer-executable instructions which, when loaded into the computer1000, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. These computer-executable instructions transform the computer1000by specifying how the CPUs1004transition between states, as described above. According to one embodiment, the computer1000has access to computer-readable storage media storing computer-executable instructions which, when executed by the computer1000, perform the various processes described above with regard toFIGS. 1-7. The computer1000can also include computer-readable storage media having instructions stored thereupon for performing any of the other computer-implemented operations described herein.

The computer1000can also include one or more input/output controllers1016for receiving and processing input from a number of input devices, such as a keyboard, a mouse, a touchpad, a touch screen, an electronic stylus, or other type of input device. Similarly, an input/output controller1016can provide output to a display, such as a computer monitor, a flat-panel display, a digital projector, a printer, or other type of output device. It will be appreciated that the computer1000might not include all of the components shown inFIG. 10, can include other components that are not explicitly shown inFIG. 10, or might utilize an architecture completely different than that shown inFIG. 10.

As shown inFIG. 10, a metric-collection component216may collect contention data218and/or other metric values that are utilized to determine how, when, how fast, and/or by how much, to adjust the batching interval136that is utilized for assigning processes132to game session requests302. The metric-collection component216may be configured to periodically, continuously, etc., collect the contention data218and provide the contention data218to a batching interval adjustment component220. The batching interval adjustment component220may be configured to, based at least in part on the contention data218, adjust the batching interval136(e.g., by updating batching interval data214) so that the assignment of processes132to game session requests302occurs at the updated/adjusted batching interval136.

While the foregoing invention is described with respect to the specific examples, it is to be understood that the scope of the invention is not limited to these specific examples. Since other modifications and changes varied to fit particular operating requirements and environments will be apparent to those skilled in the art, the invention is not considered limited to the example chosen for purposes of disclosure, and covers all changes and modifications which do not constitute departures from the true spirit and scope of this invention.

Although the application describes embodiments having specific structural features and/or methodological acts, it is to be understood that the claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are merely illustrative some embodiments that fall within the scope of the claims of the application.

Claims

  1. A computer-implemented method comprising: executing, by one or more computing devices of a game-hosting service associated with a service provider network, multiple first server processes on a fleet of virtual machine instances, the fleet of virtual machine instances being allocated to a subscriber of the service provider network and executing on computing resources of the service provider network;performing operations to assign the multiple first server processes to multiple first game session requests over a time period;detecting, based on the operations, at least one of a number or a percentage of failed attempts to assign individual ones of the multiple first server processes to the multiple first game session requests, wherein the failed attempts are caused by the individual ones of the multiple first server processes having already been assigned to a game session request;determining that the at least one of the number or the percentage of the failed attempts violates a threshold;increasing, based on the threshold being violated, a first batching interval from a first period of time to a second period of time that is greater than the first period of time to produce a second batching interval;queueing multiple second game session requests received during the second batching interval;after a lapse of the second batching interval, querying a data store for a number of second server processes executing on the fleet of virtual machine instances that are idle;assigning at least a subset of the second server processes to the multiple second game session requests as assigned server processes;and instructing the assigned server processes to host multiple game sessions corresponding to the multiple second game session requests.
  1. The computer-implemented method of claim 1 , wherein the increasing of the first batching interval comprises: increasing the first batching interval from the first period of time to an intermediate period of time to produce an intermediate batching interval, the intermediate period of time being greater than the first period of time and being less than the second period of time;determining that the at least one of the number or the percentage of the failed attempts still violates the threshold with the intermediate batching interval;increasing the intermediate batching interval from the intermediate period of time to the second period of time to produce the second batching interval;determining that the at least one of the number or the percentage of the failed attempts does not violate the threshold with the second batching interval;and ceasing to increase the second batching interval based on the at least one of the number or the percentage of the failed attempts not violating the threshold.
  2. The computer-implemented method of claim 1 , wherein the second period of time represents a highest value of a range of values over which one or more batching intervals are adjustable, the computer-implemented method further comprising: ceasing to increase the second batching interval based on the second period of time representing the highest value of the range.
  3. The computer-implemented method of claim 1 , further comprising: receiving, via a user interface presented on a computing device of the subscriber, user input to adjust a parameter to a value, the value of the parameter indicative of at least one of: an allowed level of contention allowed during game session placements;or an amount of delay allowed during the game session placements, and setting, based on the value of the parameter, one or more values corresponding to at least one of: a first rate at which one or more batching intervals are increased based on an increase in a level of contention;a second rate at which the one or more batching intervals are decreased based on a decrease in the level of contention;a threshold level of contention that triggers adjustment of the one or more batching intervals;or a range over which the one or more batching intervals are adjustable.
  4. A computer-implemented method comprising: determining, by one or more computing devices of a game-hosting service associated with a service provider network, a level of contention resulting from operations to assign processes to game session requests;adjusting, based at least in part on the level of contention, a first batching interval from a first period of time to a second period of time to produce a second batching interval;queueing one or more game session requests received during the second batching interval, the one or more game session requests including at least a first game session request;and after a lapse of the second period of time of the second batching interval, assigning, from available processes that are idle, a first process to the first game session request.
  5. The computer-implemented method of claim 5 , wherein the determining the level of contention comprises detecting, based at least in part the operations to assign the processes to the game session requests, a number of failed attempts to assign individual ones of the processes to the game session requests over a time period, wherein the failed attempts are caused by the individual ones of the processes already having been assigned to a game session request.
  6. The computer-implemented method of claim 5 , wherein the determining the level of contention comprises detecting, based at least in part on the operations to assign the processes to the game session requests, a percentage of total attempts to assign individual ones of the processes to the game session requests over a time period that corresponds to failed attempts, wherein the failed attempts are caused by the individual ones of the processes already having been assigned to a game session request.
  7. The computer-implemented method of claim 5 , further comprising determining that the level of contention violates a threshold level of contention, wherein the adjusting the first batching interval is based at least in part on the level of contention violating the threshold level of contention.
  8. The computer-implemented method of claim 8 , wherein the adjusting the first batching interval comprises: increasing the first batching interval from the first period of time to an intermediate period of time to produce an intermediate batching interval, the intermediate period of time being greater than the first period of time and being less than the second period of time;determining that the level of contention still violates the threshold level of contention with the intermediate batching interval;increasing the intermediate batching interval from the intermediate period of time to the second period of time to produce the second batching interval;determining that the level of contention does not violate the threshold level of contention with the second batching interval;and ceasing to increase the second batching interval based at least in part on the level of contention not violating the threshold level of contention.
  9. The computer-implemented method of claim 5 , wherein the adjusting the first batching interval comprises decreasing the first batching interval incrementally over a time period to the second period of time to produce the second batching interval, the second period of time being less than the first period of time.
  10. The computer-implemented method of claim 10 , wherein the second period of time represents a lowest value of a range of values over which one or more batching intervals are adjustable.
  11. The computer-implemented method of claim 5 , wherein the available processes are, prior to the assigning, executing in an idle mode on a fleet of virtual machine instances that are allocated to a subscriber of the service provider network and that are usable to host game sessions for clients of the subscriber.
  12. The computer-implemented method of claim 12 , further comprising: receiving, via a user interface presented on a computing device of the subscriber, user input to adjust a parameter to a value, the value of the parameter indicative of at least one of: an allowed level of contention allowed during game session placements;or an amount of delay allowed during the game session placements, and setting, based at least in part on the value of the parameter, one or more values corresponding to at least one of: a first rate at which one or more batching intervals are increased based on an increase in the level of contention;a second rate at which the one or more batching intervals are decreased based on a decrease in the level of contention;a threshold level of contention that triggers adjustment of the one or more batching intervals;or a range over which the one or more batching intervals are adjustable.
  13. The computer-implemented method of claim 5 , further comprising, after the lapse of the second period of time of the second batching interval: prior to the assigning the first process to the first game session request, determining a first number of the available processes that is greater than or equal to a second number of the one or more game session requests;and after the assigning the first process to the first game session request, instructing the first process to host a first game session corresponding to the first game session request.
  14. A system comprising: one or more processors;and non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the system to: determine a level of contention resulting from operations to assign processes to game session requests;adjust, based at least in part on the level of contention, a first batching interval from a first period of time to a second period of time to produce a second batching interval;queue one or more game session requests received during the second batching interval, the one or more game session requests including at least a first game session request;and after a lapse of the second period of time of the second batching interval, assign, from available processes that are idle, a first process to the first game session request.
  15. The system of claim 15 , wherein determining the level of contention comprises detecting, based at least in part on the operations to assign the processes to the game session requests, at least one of: a number of failed attempts to assign individual ones of the processes to the game session requests over a time period;or a percentage of total attempts that are the failed attempts to assign the individual ones of the processes to the game session requests over the time period, or a different time period;wherein the failed attempts are caused by the individual ones of the processes already having been assigned to a game session request.
  16. The system of claim 15 , wherein the computer-executable instructions, when executed by the one or more processors, further cause the system to: determine that the level of contention violates a threshold level of contention, and wherein adjusting the first batching interval comprises: increasing the first batching interval from the first period of time to an intermediate period of time to produce an intermediate batching interval, the intermediate period of time being greater than the first period of time and being less than the second period of time;determining that the level of contention still violates the threshold level of contention with the intermediate batching interval;increasing the intermediate batching interval from the intermediate period of time to the second period of time to produce the second batching interval;determining that the level of contention does not violate the threshold level of contention with the second batching interval;and ceasing to increase the second batching interval based at least in part on the level of contention not violating the threshold level of contention.
  17. The system of claim 15 , wherein the computer-executable instructions, when executed by the one or more processors, further cause the system to: determine that the level of contention violates a threshold level of contention, and wherein adjusting the first batching interval comprises: increasing the first batching interval from the first period of time to the second period of time to produce the second batching interval, the second period of time being greater than the first period of time, and the second period of time representing a highest value of a range of values over which one or more batching intervals are adjustable;and ceasing to increase the second batching interval based at least in part on the second period of time representing the highest value of the range.
  18. The system of claim 15 , wherein the computer-executable instructions, when executed by the one or more processors, further cause the system to determine that the level of contention violates a threshold level of contention, and wherein adjusting the first batching interval comprises decreasing the first batching interval incrementally over a time period from the first period of time to the second period of time to produce the second batching interval, the second period of time being less than the first period of time.
  19. The system of claim 15 , wherein the available processes are, prior to assigning the first process to the first game session request, executing in an idle mode on a fleet of virtual machine instances that are allocated to a subscriber of a service provider network and that are usable to host game sessions for clients of the subscriber.
  20. The system of claim 20 , wherein the computer-executable instructions, when executed by the one or more processors, further cause the system to: receive, via a user interface presented on a computing device of the subscriber, user input to adjust a parameter to a value, the value of the parameter indicative of at least one of: an allowed level of contention allowed during game session placements;or an amount of delay allowed during the game session placements, and set, based at least in part on the value of the parameter, one or more values corresponding to at least one of: a first rate at which one or more batching intervals are increased based on an increase in the level of contention;a second rate at which the one or more batching intervals are decreased based on a decrease in the level of contention;a threshold level of contention that triggers adjustment of the one or more batching intervals;or a range over which the one or more batching intervals are adjustable.

Disclaimer: Data collected from the USPTO and may be malformed, incomplete, and/or otherwise inaccurate.