คู่มือเกมแลค › L8 ซ็อกเก็ตและโปรโตคอล
โครงสร้างแบบ blocking I/O Blocking I/O model
ID สาเหตุ sk-blocking-io · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
โครงสร้างที่เธรดทำอย่างอื่นไม่ได้ระหว่างรอซ็อกเก็ตตัวเดียว จะทำให้ทั้งระบบช้าลงเมื่อคนเพิ่มขึ้น
ทำไม ใช้วิธีที่เธรดรอการอ่านและเขียนของแต่ละการเชื่อมต่อ → ผลคือ ดีเลย์ของการเชื่อมต่อหนึ่งลามไปยังการเชื่อมต่ออื่นในเธรดเดียวกัน → บนหน้าจอ ยิ่งผู้เล่นออนไลน์เพิ่มขึ้น ทุกคนยิ่งเจอสโลว์โมชั่นและอินพุตดีเลย์
- อาการ
- สโลว์โมชั่น, อินพุตดีเลย์
- ปัจจัย
- การหยุดชะงัก
- ใครเจอ
- ทั้งเซิร์ฟเวอร์
- เกิดเมื่อไร
- ตอนคนแห่มารวมกัน, ช่วงพีคหัวค่ำ
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
- งานฝั่งทีมพัฒนาเกม
- เปลี่ยนไปใช้ async I/O ที่ใช้ epoll, IOCP หรือ io_uring
- บนกราฟ
- สูงตามจำนวนคนและโหลด · เวลาตอบสนอง, จำนวนเธรด
- จุดที่ต้องดู
- จำนวนเธรดของเซิร์ฟเวอร์เกมและ voluntary context switch ของแต่ละเธรด (cswch/s คือจำนวนครั้งที่หยุดรอทรัพยากร) จาก pidstat -w -t เทียบกับเวลาตอบสนองเมื่อผู้เล่นออนไลน์เพิ่มขึ้น
- สัญญาณว่าใช่
- ยิ่งผู้เล่นออนไลน์เพิ่มขึ้น เวลาตอบสนองยิ่งพุ่งชัน และเธรดส่วนใหญ่ที่เพิ่มขึ้นตามจำนวนการเชื่อมต่อมีแต่ voluntary switch สูง แทบไม่ใช้ CPU (รอซ็อกเก็ต)
- สัญญาณว่าไม่ใช่
- เธรดใช้ CPU ต่อเนื่องโดยไม่ได้รอ: น่าจะเป็นการคำนวณเกินกำลัง (“ทิกเกินงบเวลา”)
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง
- epoll(7) — Linux manual page Linux man-pages
การแจ้งเหตุการณ์ I/O ที่ขยายให้เฝ้าดู fd จำนวนมากพร้อมกันได้ - I/O Completion Ports Microsoft
แนวทางของ Windows ที่จัดการ async I/O จำนวนมากด้วย thread pool ที่สร้างไว้ล่วงหน้า - pidstat(1) — Linux manual page sysstat
cswch/s ของ -w: voluntary context switch ที่เธรดหยุดเองเพื่อรอทรัพยากร, -t แสดงแยกตามเธรด
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L8 ซ็อกเก็ตและโปรโตคอล
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (สโลว์โมชั่น)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง