|
|
Note that since we used the same map in the above experiments, as we increase the number of players, the density of the map increases linearly and hence, the communication cost (when dominated by game update traffic) also increases linearly, as shown in Figure 7. Figure 8 shows how Colyseus scales with additional servers when we keep the object density constant by spreading 400 players uniformly across all servers. Due to inter-node interests between objects, obviously the bandwidth reduction as we add more servers will not be perfect, but we are able to achieve a 3-fold decrease in communication cost per node with a 5-fold increase in the number of nodes, so the overhead is less than a factor of 2. Nonetheless, it is clear that the returns are diminishing.
Figure 8 also breaks down the communication cost into
the different components of Colyseus: sending and routing publications
and subscriptions in Mercury (Routing), matching publications and
subscriptions (Matching), and game update traffic (Updates). The
primary reduction in per-node communication costs comes from
partitioning game update and Mercury matching traffic. This is
expected since we are explicitly diving the players among more nodes
so each node is responsble for sending less updates (though
potentially to more people), and as we increase the number of nodes
participating in the Mercury ring, each node is responsible for
matching publications for a smaller portion of the 
-range. Routing
traffic also decreases slightly as we increase the number of nodes;
despite the fact that more nodes have to forward each message to reach
the rendezvous in Mercury as we increase the number of nodes, since
the number of hops sales logarithmically with the number of nodes and
we are reducing the number of publishers-per-node linearlly, the
overall trend is a reduction in per-node traffic. In addition, caching
would reduce the number of hops in general as well.