- How to provision a cloud infrastructure hosting games
- Each bot sleeps perdiodically to reduce CPU load and instantiate more bots. Bots
connect to the game server according to a Poisson process with mean inter-arrival time of 1/λ=1s
- TIO polls game servers at regular intervals for their CPU load using SNMP. Using the raw CPU
leads to occasional over-provisionning
and higher costs, but using a moving average to smooth the CPU estimate misses CPU peaks and may result in inefficient QoS for some players.
- Since player load follows daily and weekly platterns, it's possible to anticipate the peaks; in that case, provision slightly ahead of the peak and keep a smoothed metric.
- Relevant metrics other than CPU: "slack time" = unused time during an iteration of the server loop
- DHT implementation is Pastry. It uses SHA1 to map a game zone to its owner and runner.
- Experimentation with 296 P3 1Ghz 512MB, all connected to a single 100Mbps switch. 295 machines run from 100 to 1,000 members, and a single machine runs the zone owner. Time taken to update the state of everybody is exponential with the number of zone members (average of 50ms for 500 members, 100ms for 700, 200ms for 1,000).
- Spreading users uniformly on multiple zones, each with a single zone owner, reduces the load.
- Scalability implies that nodes can be added or removed on the fly while keeping the whole system functional. Ultimate P2P goal: adding a node should increase overall system resources without consuming centralized resources.
- Cut the virtual space in Voronoi cells, where each user is at the center of his cell (deterministc algorithm). Each user connects with at least all his Vornoi neighbors (min 3, average 6, max n-1), and with more users if they are in his area of interest. Each time a user joins, moves, or leaves the game, his neighbors have to recompute their Voronoi diagram.