Can I run more than one game session on a single game server process?

This is a very important feature. For games such as ours (https://tinyrts.com) that are 1v1 RTS, pretty light network traffic, we should be able to scale very well on a single instance.

The arbitrary cap at 50 processes forces us to (50 * 2 users) 100 users maximum per instance regardless of how well we optimize the code. Being able to support multiple game sessions per server process would enable us to maximize our cost efficiency.

We'd certainly love to see this request prioritized.

Is there a link or further information on the progress of this feature? My game is also light on the Networking and would love to be able to host multiple game sessions per process

Updating GameLift to support multiple game sessions per process is certainly a request we hear from other game developers and one we are considering. Just today we released FleetIQ and Spot instances [1] that might help you reduce costs even though GameLift continues to support only 1 game session per process.

[1] https://aws.amazon.com/blogs/gamedev/reduce-cost-by-up-to-90-with-amazon-gamelift-fleetiq-and-spot-instances/

It looks like this functionality has been added. "A fleet can have many instances, each one capable of hosting multiple simultaneous game sessions ." - https://docs.amazonaws.cn/en_us/gamelift/latest/developerguide/gamelift-howitworks.html

I assume this works automatically by having each game process use a different port. Is that correct?

Yes, each instance in your fleet can run multiple copies of your game server; each game server can host a single game session. Each server runs on it own port.

You set the port in the ProcessParameters of the ProcessReady call along with the log path for that particular server.

For now the only restrictions are that each game server can only host one game sessions at a time and you can only host 50 game servers per instance.

I know this is an old thread, but it also shows the demand for the ability to run more than one game session on a single game server process since 2017, 3 years ago...

[quote="Brett_Yeager, post:6, topic:3024"] A fleet can have many instances, each one capable of hosting multiple simultaneous game sessions [/quote]

[quote="Pip, post:7, topic:3024"] For now the only restrictions are that each game server can only host one game sessions at a time and you can only host 50 game servers per instance. [/quote]

@REDACTEDUSER

This is a serious tech limitation, which leads to a cost pitfall for certain genres, especially for Realtime Servers, which been advertised as a simple message relay server + light server-side scripts.

Let me break down the reasons, taking Realtime Servers with 1v1 gameplay as an example.

Realtime Servers is based on NodeJS, an event-driven application

With NodeJS, you can run hundreds/thousands of concurrent requests per second. Because network application is usually IO-bound. This is especially true for Realtime Servers, which is mostly a messaging relay server with some light server-side logic. Think about a mobile server with 1v1 real-time battle gameplay, each player sends 1 message per second. NodeJS can still handle hundreds of game sessions in just one process.

In a real-world example, back to 10 years ago, a 1v1 gameplay battle game I operated with a similar (and simple) messaging relay architecture hosting on an old AMD Opteron 6128 (Cores: 8, Threads: 8, Single thread rating: 447 cpubenchmark.net) 2.0Ghz 32G memory can handle 5K CCU. It means each CPU thread can handle 625 CCU, roughly 300+ game sessions.

To convert it into a modern cloud environment, for c5.large (the smallest server spec you can rent with GameLift) is a 1 CPU core, 2 threads (vCPU), 4G mem box that running on Intel Xeon Platinum 8124M @REDACTEDUSER

With the restrictions of GameLift's one game server process can only host one game session, and up to 50 server processes on an instance. That means c5.large can only handle 50 game sessions (100 CCU). A huge waste of resources, money, and the scalability of NodeJS.

The 50 game server processes per instance limitation could be memory-bound

NodeJS is running on V8. Some sources suggest a 64MB~256MB is a sufficient amount of RAM to run Node.js (refs).

With c5.large, 4G / 50 ~= 82MB, near to the lowest memory requirements. You need to be more careful about the actual number of game server processes you can run on a small instance. It could be fewer.

The 50 game server processes per instance limitation are not scalable with EC2 specs

Let's say 50 is a reasonable number for c5.large. Now with c5.4xlarge, I should expect 4 times more game server processes, but you still have 50 there. Does it make sense? That pushes developers to make a decision to find a server spec that can just run up to 50 game server processes, get anything more powerful is a waste.

The 50 game server processes per instance limitation didn't take different players-per-session into account.

With 50 game sessions/instance, 1v1 gameplay has 100 CCU, 2v2 gameplay has 200 CCU, 10v10 gameplay has 1000 CCU. I'm okay with 1000 CCU on a c5.large. But I shouldn't purchase far more instances just because my gameplay requires fewer players per session.

• on-demand pricing for c5.large is estimated as $40.
• spot pricing for c5.large is roughly estimated as $15.
• home-made pricing is based on c5.large on-demand pricing.

Can GameLift support multiple sessions per game server process?

It doable but certainly more complex to implement the feature because GameLift has to trust more your game server to correctly manage game sessions. Memory leaking can be a big issue as well. GameLift has to implement more complex schedule logic to restart your game server process to avoid memory leaking.

But on another hand, I'm not sure if we can do the homework ourselves. Even you can call multiple ProcessReady and successfully cheat GameLift to run multiple sessions per game server process, you may break the GameLift server schedule logic.

Conclusions

• GameLift is good if you have a 5v5 or 10v10 gameplay. The more players-per-session, the fewer impacts on you from the limitation.
• GameLift is okay for 1v1, 2v2 with complex game logic on the server-side, which you won't expect a large CCU per instance.
• GameLift is questionable for 1v1, 2v2 with simple game logic on the server-side. Especially the Realtime Servers which advertised for the simple messaging games. It is less cost-effective (card battle and turn-based genres). It should be a strong selling point for using GameLift Realtime Servers though. IMO without the feature, the entire Realtime Servers idea is useless or at least value dropped.

It's a feature request since 3 years ago. Will GameLift plan resources on this feature eventually? Or at least make it possible for developers to implement it themselves?

Feedbacks are welcome.

I have the same question as @REDACTEDUSER

Also, I'm interested in spawning more game servers per game server since it will improve resource usage and will be more secure (since different game sessions will have different processes). Limit 50 per instance is too low for me since my game server seems to be VERY lightweight.

Really, in such cases (very lightweight game session) FMPOV AWS Fargate seems like much more suitable since we can simply spawn one ECS task per game session and use features like FlexiMatch directly from ECS task. Maybe I'm wrong - any help is appreciated!

Thanks in advance!

Just notice that Flexmatch can be very expensive if you use it as a standalone component, especially of 1v1 or 2v2 gameplay. https://forums.awsgametech.com/t/flexmatch-pricing/10458

If you use AWS Fargate then more or less you're rolling out a homemade solution for the entire stack.

GameLift may be less serious for lightweight servers which requires much less AWS resources (less $).

Thanks for your thoughtful reply,

Hosting multiple sessions per process is really important to some potential GameLift customers and has been in the feature backlog for a while. However, theres no committed date for this feature and unfortunately GameLift doesn't have a public roadmap. I am pinging the GameLift team so they can see your posts and followup with both of you.

Your talk about Fargate made me wonder if you've seen these:

• GameLift for ECS: https://github.com/aws-samples/amazon-gamelift-fleetiq-with-amazon-ecs
• https://forums.awsgametech.com/t/gamelift-support-for-agones-and-elastic-kubernetes-service/10514

Thanks for all the data.

@REDACTEDUSER

Hosting multiple sessions per process is really important to some potential GameLift customers and has been in the feature backlog for a while

Consider not only "multiple game sessions per process approach". I think another possible solution can be just to increase the process count limit per instance. In my case, a game server will be quite lightweight based on Rust and bevy_ecs, memory and CPU consumption will be low, so I can easily spawn more than 50 processes per instance. However, for some use cases (e.g. where we REALLY try to get as less overhead as possible), having a model "one game session per thread" if also fine.

Yeah, will be an overhead per process but that's a price for security and crash-tolerance, which I am ready to pay. Will be awesome, if I will be able to increase the process count limit per instance via AWS support or something like that. Even it will be in a "beta" state - that's completely fine for me.

If you need any details from my side or get any further details, which can be helpful for AWS GameLift team - feel free to ping me here or give my email :)

Completely agree with you. What I am trying to do now - find cost-efficient solution and at the same time don't reimplement GameLift stack from the scratch :)

Any updates on this? In the same boat. Have a lightweight PVP RT game and only having large instances limited to 50 i think is overkill.

Recently I've got a response from AWS Support team:

=================================================================================================================== Good morning,

At this time GameLift Fleets only support a maximum of 50 processes per instance, but I have recorded this feature request with the service team so we can keep track of it. This feedback is invaluable to us as our feature roadmap is driven by customer feedback like this.

GameLift FleetIQ (Game Server Groups) can support a much high count of processes per instance. See if GameLift Game Server Groups fits your use-case: https://docs.aws.amazon.com/gamelift/latest/fleetiqguide/gsg-intro.html

Please let us know if you have any questions!

Thank you, Dan

===================================================================================================================

So, as you see, now there is no way to spawn more than 50 instances per node on fully managed GameLift.

Looks like I've completely wasted my time the last few days implementing gamelift in our game, as its a card game with a simple relay based server, so this arbitrary limitation of 50 game servers per instance makes it completely useless, and devs have been promising to look into it for more than 4 years now!

If Amazon is unwilling or unable to increase the 50 process per server limit, can you at least allow smaller EC2 instances? Right now c5.large is the smallest. I am able to run a nodejs server that supports 25000 users on a single t3.medium instance (with a Relay server type setup). Having 50 “games” on c5.large is an incredible waste of resources. If 50 is the maximum, then you should allow t3.micro servers at least. I know there are other considerations such as network performance of these smaller instances, but leave that up to us, the developers, to consider.

Any chance to get a response from AWS regarding adding support for smaller instances or a higher concurrent process count? There are marketing and technical materials presenting Realtime as a service targeted for simple games, but this issue makes many of these use-cases potentially prohibitively expensive when scaling up a business, or simply very wasteful, for seemingly no good reason. It's quite a painful realization down the road for studios such as ours which have already invested some time in integrating with GameLift.

Did anyone consider/experiment with manually managing "nested" game sessions? Perhaps manually managing game sessions inside Realtime scripts could be a workaround to this issue while still leveraging most of the advantages of running a fully managed stack.