คู่มือเกมแลค › L9 โปรเซสเกมฝั่งเซิร์ฟเวอร์

การคำนวณระยะมองเห็น (AOI) พุ่ง (N²) Area-of-interest explosion

ID สาเหตุ sp-aoi · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)

เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →

ถ้าเปรียบเทียบทุกคนกับทุกคนเพื่อหาว่าใครมองเห็นใคร เมื่อจำนวนคนเพิ่มเป็น 10 เท่า การคำนวณจะเพิ่มเป็น 100 เท่า

ทำไม เทียบระยะห่างระหว่างตัวละครทุกตัว หรือแม้แบ่งเป็นตาราง (grid) แล้วก็ยังมีคนหลายร้อยคนกระจุกรอบเซลล์เดียว → ผลคือ 100 คนเทียบประมาณ 1 หมื่นครั้ง 1,000 คนเทียบประมาณ 1 ล้านครั้ง → บนหน้าจอ ในที่ที่คนกระจุกตัว เช่น เวิลด์บอสหรือศึกชิงปราสาท ทิกพุ่ง: สโลว์โมชั่น, กระตุก

อาการ

สโลว์โมชั่น, กระตุก

ปัจจัย

การหยุดชะงัก

ใครเจอ

บางจุด/บางแชนแนล, ทั้งเซิร์ฟเวอร์

เกิดเมื่อไร

ตอนคนแห่มารวมกัน

ผู้รับผิดชอบ

ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)

งานฝั่งทีมพัฒนาเกม

แบ่งเป็นตารางหรือเขตแล้วเทียบเฉพาะที่อยู่ใกล้, อัปเดตเป้าหมายที่อยู่ไกลให้ห่างขึ้น, จำกัดจำนวนคนที่ผู้เล่นหนึ่งคนมองเห็น

ตัวเลขที่ควรรู้

ถ้าคิดการเทียบระยะและการอัปเดตรายการว่าเห็นหรือไม่เห็นรวมกันเป็น 0.1 µs (หนึ่งในสิบล้านวินาที) ต่อหนึ่งคู่ 1,000 คน (ประมาณ 1 ล้านคู่) จะใช้ 100 ms ต่อทิก เป็นสองเท่าของงบเวลาที่ 20 ทิก (50 ms)

บนกราฟ

สูงตามจำนวนคนและโหลด · เวลาต่อทิกของเซิร์ฟเวอร์, จำนวนคนที่รวมตัวในจุดเดียว

จุดที่ต้องดู

จำนวนผู้เล่นและเวลาต่อทิกแยกตามโซน/แชนแนลบนกราฟเดียวกัน และเวลาที่ใช้คำนวณระยะมองเห็นในทิกซึ่งวัดแยกไว้ ถ้าไม่ได้วัดแยก ให้ดูสัดส่วน CPU แยกตามฟังก์ชันของโปรเซสเกมด้วย perf top -p

สัญญาณว่าใช่

เมื่อจำนวนคนในจุดเดียวเพิ่มเป็น 2 เท่า เวลาต่อทิกเพิ่มเกือบ 4 เท่า และฟังก์ชันคำนวณระยะมองเห็นและระยะห่างกินเวลา CPU ส่วนใหญ่

สัญญาณว่าไม่ใช่

เวลาต่อทิกเพิ่มเป็นสัดส่วนตรงกับจำนวนคน หรือฟังก์ชันส่งข้อมูลและ serialization กินสัดส่วนมาก: น่าจะเป็นปริมาณ broadcast พุ่ง หรือต้นทุนของ serialization และการบีบอัด

วิธีตรวจ

ต้องมี log หรือเมตริกจากเซิร์ฟเวอร์/ไคลเอนต์เกม

แหล่งอ้างอิง

1. Comparing Interest Management Algorithms for Massively Multiplayer Games ACM
   เปเปอร์ NetGames 2006 (ฉบับที่ผู้เขียนเผยแพร่เอง) วิธีวัดระยะทุกคู่รับไม่ไหวเมื่อจำนวนคนเพิ่มขึ้น และถ้าแบ่งเป็นตารางสี่เหลี่ยมจัตุรัส จะตรวจเฉพาะ 9 เซลล์โดยรอบ
2. Replication Graph in Unreal Engine Epic Games
   วิธีพื้นฐานที่ไล่ตรวจทุกการเชื่อมต่อสำหรับ actor แต่ละตัว จะเป็นคอขวด CPU ของเซิร์ฟเวอร์เมื่อผู้เล่นและ actor มีจำนวนมาก, MMORPG และเกมลักษณะเดียวกันแบ่งโลกเป็นตารางและใช้รายการของแต่ละเซลล์ซ้ำ
3. perf-top(1) — Linux manual page perf
   แสดงสัดส่วนการใช้ CPU ของโปรเซส (-p) หรือเธรด (-t) ที่กำลังรันแยกตามฟังก์ชัน (symbol) แบบเรียลไทม์

สาเหตุที่ควรดูประกอบ

ชั้นเดียวกัน: L9 โปรเซสเกมฝั่งเซิร์ฟเวอร์

• ทิกเกินงบเวลา
• ปริมาณ broadcast พุ่ง
• พื้นที่ที่รันบนเธรดเดียวโหลดเกิน (hotspot)
• การแย่งล็อก
• เดดล็อก
• synchronous call บนเธรดเกม
• ข้อความสะสมในคิว
• ตัวจับเวลาทำงานพร้อมกันจำนวนมาก
• การคำนวณ pathfinding พุ่ง
• ต้นทุนของ serialization และการบีบอัด
• เซิร์ฟเวอร์แครช
• thread pool หมด
• ลูปไม่รู้จบ/ลอจิกทำงานไม่หยุด
• การต่อสู้ที่รุมเป้าหมายเดียว (เวิลด์บอส)
• spawn ทะลักเมื่อเข้าพื้นที่คนหนาแน่น
• เอนทิตีสะสม (ไอเทม/ซัมมอนที่ไม่ถูกเก็บกวาด)
• แพตช์ทำให้รูปแบบทราฟฟิกเปลี่ยน

สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (สโลว์โมชั่น)

• fixed timestep ไล่ตามไม่ทันจนบานปลาย L1 โปรเซสเกมฝั่งไคลเอนต์
• โหลดบาลานเซอร์กระจายไม่เท่ากัน/health check ตัดสินผิด L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์
• เธรดมากเกินไปและ context switch L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
• CPU throttling ของคอนเทนเนอร์ (CFS quota) L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
• ความหน่วงพุ่งจากการจัดการพลังงานของเซิร์ฟเวอร์ (C-state/การปรับความถี่) L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
• งานตามกำหนดเวลา (scheduled job) L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
• ประสิทธิภาพเปลี่ยนไปหลังอัปเดต OS/เคอร์เนล/ไดรเวอร์/เฟิร์มแวร์ L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
• การส่งแบบ blocking เพราะไคลเอนต์ช้า L8 ซ็อกเก็ตและโปรโตคอล

ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง