Sign In Register

How can we help you today?

Start a new topic
Answered

Performance, Load, Scaling, Concurrent users

Can I have more details about how you manage large number of CCU?

I found that in Preview there is limit of 100 CCU. What is standard limit for LIVE stage? (I know It strongly depends on the application, cloud code, number of reqests). Maybe number of requests per hour will be more  

How do you react to the increasing load? What is being done? Scaling servers? Introducing shards in MongoDB?

And how looks basic LIVE MongoDB configuration?


I'm just worried about the future if the game would become a hit, and reach over 100k-500k DAU


Best Answer

Hi Zbigniew,


GameSparks deploys each customer game on a set of resources known as a Runtime Cluster. A Runtime Cluster contains all of the resources necessary for a running game, namely API services and data stores. We regularly scale the resources of all our Runtime Clusters up and based on player traffic.


Should a game have a rapid increase in concurrently connected users, GameSparks’ monitoring systems will instantly provision more resources within the Runtime Cluster that is hosting that game. This is currently either horizontal scaling of the API services layer or vertical scaling of any of the data stores. We do not currently shard any of our MongoDB clusters as this has not been necessary to date.


In order to avoid the bottlenecks associated with traditional network load balancing, the GameSparks Runtime Clusters use a proprietary technique similar to many DNS-based GLB offerings. At the start of a session, each client makes a single request to the GameSparks load balancers, which in turn re-direct that client to a specific API server within the Runtime Cluster that their game runs on. The client then uses this permanent WebSocket connection until the client closes it or there is a failure. Should there be a connection failure, the client follows the same process of establishing a new connection. All of this connection process is managed by the GameSparks SDK.


This approach means that as we horizontally scale the API services layer within a Runtime Cluster, we know that each new server can handle a consistent number of connections without any intermediate network component adding a bottleneck.


We have stress tested – and run in Production – a Runtime Clusters with over 100,000 concurrently connected players. We don’t impose a limit on concurrently connected players, but if you’re expectations are well in excess of this number then we’d be happy to work with you on a representative load test.


Thanks,

Liam


Answer

Hi Zbigniew,


GameSparks deploys each customer game on a set of resources known as a Runtime Cluster. A Runtime Cluster contains all of the resources necessary for a running game, namely API services and data stores. We regularly scale the resources of all our Runtime Clusters up and based on player traffic.


Should a game have a rapid increase in concurrently connected users, GameSparks’ monitoring systems will instantly provision more resources within the Runtime Cluster that is hosting that game. This is currently either horizontal scaling of the API services layer or vertical scaling of any of the data stores. We do not currently shard any of our MongoDB clusters as this has not been necessary to date.


In order to avoid the bottlenecks associated with traditional network load balancing, the GameSparks Runtime Clusters use a proprietary technique similar to many DNS-based GLB offerings. At the start of a session, each client makes a single request to the GameSparks load balancers, which in turn re-direct that client to a specific API server within the Runtime Cluster that their game runs on. The client then uses this permanent WebSocket connection until the client closes it or there is a failure. Should there be a connection failure, the client follows the same process of establishing a new connection. All of this connection process is managed by the GameSparks SDK.


This approach means that as we horizontally scale the API services layer within a Runtime Cluster, we know that each new server can handle a consistent number of connections without any intermediate network component adding a bottleneck.


We have stress tested – and run in Production – a Runtime Clusters with over 100,000 concurrently connected players. We don’t impose a limit on concurrently connected players, but if you’re expectations are well in excess of this number then we’d be happy to work with you on a representative load test.


Thanks,

Liam

That is great information thanks.


An obvious followup question would be, how heavy was the simulated load of the 100K CCU per player?  How active was each simulated player?  How many API calls per second?


Also, you said WebSocket, but I presume for Unreal/C++ the same applies to the native socket (or however it's establishing the TCP connection).


Thanks!

Hi Steven,


During testing we’ve comfortably handled in excess of 6,000 API calls per second on a Runtime Cluster. The number of calls per second is just one dimension of performance though, as the flexibility of the GameSparks platform means that the load generated per call can be very different. For our tests, we ran a blend of compute and data store activity in our calls. As your game’s usage profile may be different to this, we would recommend that you share your load requirements so we can perform a representative load test with you if necessary.


The Unreal/C++ SDK uses WebSocket connections to our platform, giving the same bi-directional, asynchronous communication as all our other SDKs.


Thanks,

Liam

Login to post a comment