To quantify the limitations of the client-server architecture, we evaluate the performance of one such game: Quake II. In Figure 1, we show the performance of a Quake II server supporting differing number of clients on a Pentium-III 1GHz machine with 512 MB RAM. Quake II implements both area-of-interest filtering and delta-encoding. The Quake II server is configured with an update frequency of 10 times per second. The server does not rate-limit the clients, i.e., sends updates to all entities within the area-of-interest for each frame. Client movements are simulated using server-side AI bots. Bots are essentially computer-controlled players. The simulation is run for a 10-minute game and the metrics reported are mean values over the entire session.
Figure 1(a) shows the frames per second actually computed by the server, while Figure 1(b) shows the bandwidth consumed at the server for sending updates to these clients. We note several points: first, as the number of players increases, area-of-interest filtering computation becomes a bottleneck3 and the frame rate drops. Second, Figure 1(b) shows that, as the number of players increases, the bandwidth-demand at the server increases much more than linearly. As the number of players increases, players interact more with each other (more missiles are shot, for example). Thus, NumAoiObjs increases along with NumClients resulting in more than linear increase in bandwidth. This result shows that the bandwidth rate-limiting done by most current game-servers will adversely impact perceived game-play. Finally, we note that, for large #players, computational load becomes the bottleneck and the reduction in frames per second offsets any increase in bandwidth due to an increase in the number of clients.
Although the absolute limits shown can be pushed by a factor of 2 or 3 by employing more powerful servers, these results demonstrate that a centralized client-server system quickly becomes a bottleneck.