[aceoflolo]

>We wanted to provide a bit more context for the most recent login issues and service instability. All of our cloud services are affected by updates required to mitigate the Meltdown vulnerability. We heavily rely on cloud services to run our back-end and we may experience further service issues due to ongoing updates.

So they are saying "you can't log in because we're too cheap to rent more servers now that this patch has increased CPU usage"

[transpostmeta]

Resolving scalability issues is not as simple as "rent more servers".

[TrickyRick]

Renting beefier servers may also be an option if the performance impact scales linearly with pre-patch performance. However it's not clear in this case how that works.

[bhouston]

Depends if the bottleneck is a single CPU or whether it is a single machine. Those beefier machines are usually slower per CPU.

I've seen some crazy game server designs before in the quest to have fast response times. But UE4 is pretty professional so even if they are tied to a single machine, they probably are not tied to a single core for some of their critical algorithms I would hope.

[aceoflolo]

For a CPU-bound problem it mostly is as simple as that, yes

[bhouston]

Only if the algorithm can be split across multiple machines easily.

Sometimes people assume that you can use local shared memory or something between threads in order to synchronize state. You figure out how many individuals can be on a server at once and then ensure that you can handle that load on a specific machine.

I've seen this type of stuff for game state before because they need to keep everyone in a specific game domain (level or city depending on the type of game) synchronized and be nearly real-time. It can be hard to pull this across different machines without introducing significantly latency, redis or DBs is slow for a FPS shootter.

Not saying this is the case but I can see it could be something like that.

[tetha]

Yup. When I was in a team working on distributed game servers, this forced us to shard games instead of distributing individual games.

Terminology wise, if a game session was fully distributed across multiple instances, each server could accept traffic for this game session. Think elasticsearch - each node can answer searches for any index in the cluster.

If you shard your games, you just put all games with an even ID on box 1 and all games with an odd ID on box 2. If box 1 dies, all games on that box disappear. And then you usually end up with a lobby server as an initial connection and redirect to the actual game server in the background.

This is a very simple architecture. It's easy to develop for this architecture, because you don't need to worry about complex clustering issues - exactly 1 client talks to exactly 1 server and it doesn't matter if there's 50 other servers answering other clients.

This is also very nice to scale. Most server side code for games tends to have very predictable resource consumption, because it's running a pretty predictable simulation loop on a pretty predictable and bounded data set. Especially from this perspective, I can see why the Epic guys are bugged. It's not pretty to put a factor of 2 into those calculations.

[Sir_Substance]

You're making assumptions about a software stack you haven't seen.