คู่มือเกมแลค › L9 โปรเซสเกมฝั่งเซิร์ฟเวอร์
ต้นทุนของ serialization และการบีบอัด Serialization / compression cost
ID สาเหตุ sp-serialize · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
การแปลงข้อมูลที่จะส่งเป็นไบต์และบีบอัดก็ใช้ CPU เช่นกัน และเมื่อคนเยอะ ต้นทุนนี้จะพุ่งสูง
ทำไม แปลง struct เป็นไบต์และบีบอัดทุกครั้งที่อัปเดต → ผลคือ ต้นทุนเพิ่มตามจำนวนคนยกกำลังสอง → บนหน้าจอ การส่งช้าลงจนเกิดอินพุตดีเลย์
อาการ อินพุตดีเลย์
ปัจจัย การหยุดชะงัก, ความหน่วง
ใครเจอ บางจุด/บางแชนแนล
เกิดเมื่อไร ตอนคนแห่มารวมกัน
ผู้รับผิดชอบ ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม)
งานฝั่งทีมพัฒนาเกม ใช้แพ็กเก็ตที่สร้างครั้งเดียวซ้ำกับหลายคน, ใช้ฟอร์แมตที่เบา
บนกราฟ สูงตามจำนวนคนและโหลด · อัตราการใช้ CPU ของเซิร์ฟเวอร์, CPU ของเธรดที่สร้างแพ็กเก็ต
จุดที่ต้องดู สัดส่วนเวลา CPU ของโปรเซสเกมที่ใช้ในฟังก์ชัน serialization การบีบอัด และการเข้ารหัส (รวมฟังก์ชันของไลบรารีอย่าง zlib, LZ4 และ OpenSSL) จาก perf top -p เทียบระหว่างตอนคนน้อยกับตอนคนแห่ สัญญาณว่าใช่ ยิ่งคนแห่มาก สัดส่วนของฟังก์ชัน serialization การบีบอัด และการเข้ารหัสยิ่งสูง และ CPU ของเธรดที่สร้างแพ็กเก็ตเต็มก่อน สัญญาณว่าไม่ใช่ ฟังก์ชันเหล่านี้กินสัดส่วนน้อย: น่าจะเป็นการคำนวณระยะมองเห็นหรือลอจิกของเกม วิธีตรวจ ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
รายละเอียดเพิ่มเติม ถ้าการเชื่อมต่อเข้ารหัสแพ็กเก็ต (TLS, DTLS เป็นต้น) การเข้ารหัสและถอดรหัสก็ใช้ CPU ด้วย การเข้ารหัสทำแยกต่อการเชื่อมต่อ ต่อให้ใช้แพ็กเก็ตที่สร้างครั้งเดียวซ้ำกับหลายคน ต้นทุนการเข้ารหัสก็ยังเพิ่มตามจำนวนผู้รับ การเข้ารหัสแบบสมมาตรอย่าง AES-GCM เร็วพอที่คอร์เดียวจะประมวลผลได้หลาย GB ต่อวินาที ปกติจึงกินสัดส่วนน้อย แต่ความเร็วจะต่างกันมากตามขนาดของหน่วยที่เข้ารหัสในครั้งเดียว (record) ถ้ามีแพ็กเก็ตเล็กจำนวนมากแบบเกม ต้นทุนต่อไบต์จะสูงขึ้น ใน handshake ที่ทำครั้งเดียวต่อการเชื่อมต่อ เซิร์ฟเวอร์ต้องเซ็นด้วยคีย์ของใบรับรองและคำนวณการแลกเปลี่ยนคีย์ (ECDHE) คอร์เดียวเซ็นได้ประมาณ 1,100 ครั้ง (RSA 2048) ถึง 18,000 ครั้ง (ECDSA P-256) ต่อวินาที และแลกเปลี่ยนคีย์ได้ประมาณ 9,000 ครั้ง จึงเป็นภาระเมื่อคนแห่ล็อกอิน
แหล่งอ้างอิง Introduction to Iris in Unreal Engine Epic Games เก็บสถานะที่ต้อง replicate เป็นสำเนาที่ quantize แล้วชุดเดียวเพื่อลดงานที่หนัก และให้หลายการเชื่อมต่อใช้งานนั้นร่วมกัน VALORANT's 128-Tick Servers Riot Games วิธีเทียบตัวแปรที่ replicate ของไคลเอนต์แต่ละรายทุกเฟรมแล้วรวบรวมค่าที่เปลี่ยน ต้องอ่านหน่วยความจำกระจัดกระจาย ซึ่งช้าและกิน CPU ของเซิร์ฟเวอร์มาก How "expensive" is crypto anyway? Cloudflare ผลวัดของ BoringSSL: AES-128-GCM ประมาณ 3.7 GB ต่อวินาที (ต่างกันมากตามขนาด record), คอร์เดียวต่อวินาทีทำ RSA 2048 signature ได้ 1,120 ครั้ง, ECDSA P-256 signature 18,477 ครั้ง และ P-256 ECDHE 9,394 ครั้ง, บนเอดจ์เซิร์ฟเวอร์ของ Cloudflare ไลบรารี TLS ใช้ CPU ประมาณ 1.8% perf-top(1) — Linux manual page perf แสดงสัดส่วนการใช้ CPU ของโปรเซสที่กำลังรัน (-p) แยกตามฟังก์ชัน (symbol) แบบเรียลไทม์
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L9 โปรเซสเกมฝั่งเซิร์ฟเวอร์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (อินพุตดีเลย์)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง