Locality Aware Dynamic Load Management for Massively Multiplayer Games Written by Jin Chen 1, Baohua Wu 2, Margaret Delap 2, Bjorn Knutsson 2, Honghui Lu 2, Cristiana Amza 1 University of Toronto 1 & University of Pennsylvania 2 PPoPP ’ 05 (ACM Principles and Practice of Parallel Computing) Presented by Te-Yuan Huang

2/33 Players ’ Expectation of Massively Multiplayer Online Games (MMOGs)  A large number of players (e.g., 100K)  Update interval is crucial to players Picutre CopyRight © Jin Chen

3/33 State-of-Art Scalability Solutions  Admission Control Implemented at gateways (ex: airport, doors)  Separated mini-world Connected by airport, door … etc Server

4/33 The Goal of this Paper  Contiguous world  Seamless partition Players can “ see ” across server boundaries Players can smoothly transfer  Inter server communication Boundary information Player handoff CopyRight © Jin Chen

5/33 How to distribute Load?  Static Partition row based column based cyclic … etc  Dynamic Partition Game World.....

6/33 The Load Balancing Problem  Flocking (eg, Festivals 、 Quests..etc) Players move to one area or hotspot Overload the server hosting the hotspot Static partitioning is impractical! CopyRight © Jin Chen

7/33 State-of-Art Dynamic Load Management Algorithms  Dynamic Uniform Load Spread – SPREAD Tries to minimize the difference between most and least loaded nodes Optimize overall load balance Server 1 Server 2

8/33 State-of-Art Dynamic Load Management Algorithms  Dynamic Load Shedding to Lightest Loaded Node Known - Lightest Shed load to system-wide lightest loaded node Optimize remap cost I am overloaded!QQWho is the lightest? I am Server 1 Server 2

9/33 Are they good enough?  No! Why? Locality is ignored! Less locality, higher inter-server communication Keep adjacent regions on same server Without Locality With Locality

10/33 Objective of New Algorithm  Balancing the server load By shed the partition across more servers  Decreasing inter-server communication By take locality into account By aggregate adjacent regions

11/33 Graph Representation of the Game World Locality: Keep minimum number of connected component

12/33 Flow Chart of the Algorithm QoS Violation Why!? Load Shedding Load Aggregation Too many Clients Too Many Inter-Server Communications Goal: Balance load & maintain locality Goal: Correct locality disruption

13/33 QoS Violation Definitions  SLA Violation SLA: Service Level Agreement For 90% clients Update interval > predefined value  Overload Threshold (Overload_th) The Min number of clients in a server can cause SLA violation A server is overload, when its client number > overload_th  Safe Load Threshold (Safety_th) The target of load shedding The MAX number of clients in a server and no SLA violation

14/33 SLA Violation Why!? Load Shedding Load Aggregation Clients Num > Overload_th Too Many Inter-Server Communications Goal: Balance load & maintain locality Target: Clients Number = Safety_th Goal: Correct locality disruption Flow Chart of the Algorithm

15/33 Load Shedding Algorithm  Shed to whom? First Priority: Neighbor Second Priority: Remote Lightly-loaded Servers  How to define lightly-loaded? Light_load_th = 2*Safety_th – Overload_th Light_load_th + Overload_th = 2*Safety_th  Break the connected component into two

16/33 Load shedding Quest! CopyRight © Jin Chen

17/33 Load shedding under quest CopyRight © Jin Chen

18/33 Load shedding to neighbors CopyRight © Jin Chen

19/33 Load shedding to lightly loaded servers Added more inter-server communication! CopyRight © Jin Chen

20/33 Locality aware aggregation  Triggered by SLA violations & load is normal  Aggregation Merge boundary regions into neighbor partitions

21/33 Locality aware aggregation (1) CopyRight © Jin Chen

22/33 Locality aware aggregation (2) CopyRight © Jin Chen

23/33 Evaluation Methodology  Single server experiments with Simmud A MMOG game server from UPenn  Determine algorithm parameters  Collect traces  Simulate a large scale game

24/33 Experiment Result – Single Server Bandwidth Utilization 33 second for 144 players214 millisecond for 128 players

25/33 Experiment Result – Single Server Bandwidth Utilization Does not reach peak Clients time-out & drop The main bottleneck is server-client bandwidth

26/33 Experiment – Multiple Server server1 server2 server3server4 Quest! 128 players Quest set at t=65 update every 3 seconds Players at server 4 passing by Quest setup

27/33 Experiment Result – Multiple Server CPU Utilization BW Utilization CPU Utilization correlates with players

28/33 Simulation Settings  Simulation Parameters Overload_th : 128 players Safety_th : 80 players Light_load_th : 32 players SLA: 2 seconds  Environment 100 servers and 400 regions 6000 independent players  Traces collected from SimMud

29/33 Simulation Settings – Cont.  A LAN-based server system 100 Mbps inter-server bandwidth 100 Mbps server-players bandwidth  A WAN-based server system 100 Mbps shared network bandwidth towards both its players and neighbor servers  Algorithm applied Static partition Spread Lightest Locality Aware Dynamic Algo.

30/33 Simulation Results – LAN-based server SLA Crowds in single region

31/33 Simulation Results – WAN-based server

32/33 Simulation Results – Distributed WAN-based server (Cont.) Without Merge, it performs bad after the quest is over.

33/33 Simulation Results – Distributed WAN-based server (Cont.) MetricLocalityLocality w/o M LightestSpread # of Region Remap # of Connected Components

34/33 Conculsion  Presented a load management algorithm Supports seamless game world partitioning Uses a locality aware algorithm Combined load shedding and partition merging  Achieves better performance (SLA) Up to a factor of 8 compared to Static Up to a factor of 6 compared to global reshuffle  My opinion Complete Work Great Simulation Complicated Algorithm