คู่มือเกมแลค › การออกแบบการซิงก์
โปรโตคอลที่ต้องไปกลับตามลำดับหลายรอบ (chatty) Chatty protocol / sequential round trips
ID สาเหตุ sy-chatty · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ถ้าการกระทำหนึ่งครั้งต้องไปกลับเซิร์ฟเวอร์หลายรอบตามลำดับ ปิงจะคูณตามจำนวนรอบนั้น
ทำไม เปิดร้านค้า → ขอรายการ → ตรวจราคา → ซื้อ → อัปเดตกระเป๋า แยกเป็นคำขอทีละรายการ → ผลคือ ต้องได้คำตอบของคำขอก่อนหน้าก่อนจึงส่งคำขอถัดไป → บนหน้าจอ ที่ปิง 150 ms ซื้อของครั้งเดียวใช้เวลาเกือบ 1 วินาที และโหลดนานผิดปกติ
- อาการ
- อินพุตดีเลย์, เข้าเกมไม่ได้/โหลดไม่จบ
- ปัจจัย
- ความหน่วง
- ใครเจอ
- เฉพาะบางฟีเจอร์, เราคนเดียว
- เกิดเมื่อไร
- ตอนทำแอ็กชันบางอย่าง, หลังล็อกอิน/หลังปิดปรับปรุง
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
- งานฝั่งทีมพัฒนาเกม
- เซิร์ฟเวอร์: เปลี่ยนโปรโตคอลให้รวมหลายขั้นตอนไว้ในคำขอและคำตอบเดียว (เช่น ใส่กระเป๋าที่อัปเดตแล้วไว้ในคำตอบของการซื้อด้วย) ไคลเอนต์: โหลดข้อมูลที่ต้องใช้ไว้ล่วงหน้า, ทำ UI ที่ไม่ต้องรอผลลัพธ์
- ตัวเลขที่ควรรู้
- เวลาที่ใช้ ≈ จำนวนรอบไปกลับ × (ปิง + เวลาประมวลผลบนเซิร์ฟเวอร์ + เวลารอทิก) ถ้า 5 รอบที่ปิง 150 ms จะใช้ประมาณ 0.85–1 วินาที
- บนกราฟ
- สูงตลอดตั้งแต่แรก · เวลาที่แต่ละฟีเจอร์ใช้จนเสร็จ, จำนวนรอบไปกลับต่อการกระทำหนึ่งครั้ง
- จุดที่ต้องดู
- ใน packet capture ฝั่งเซิร์ฟเวอร์ (Wireshark) นับว่าระหว่างที่บัญชีทดสอบกดซื้อของในร้านหรือล็อกอินหนึ่งครั้ง คำขอและคำตอบสลับกันไปมากี่รอบ และห่างกันเท่าไร ถ้ามี log คำขอของเซิร์ฟเวอร์ ให้จัดกลุ่มด้วย session ID แล้วดูจำนวนคำขอและเวลาที่แต่ละคำขอมาถึงและได้คำตอบ
- สัญญาณว่าใช่
- การกระทำหนึ่งครั้งมีคำขอที่ต้องรอคำตอบก่อนหน้าแล้วจึงส่งต่อกันหลายรอบ เวลาที่ใช้จนเสร็จประมาณจำนวนรอบ × RTT และผู้เล่นในพื้นที่ที่ปิงสูงจะใช้ฟีเจอร์เดียวกันได้ช้าลงตามสัดส่วน
- สัญญาณว่าไม่ใช่
- ไปกลับแค่หนึ่งสองรอบ แต่คำตอบเดียวใช้เวลานาน: น่าจะเป็นสาเหตุที่การประมวลผลบนเซิร์ฟเวอร์หรือ DB ถ้าผู้เล่นทุกคนช้าเท่ากันโดยไม่เกี่ยวกับปิง ให้ดูโหลดของเซิร์ฟเวอร์
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง
- Chatty I/O antipattern Microsoft Azure
ถ้ามีคำขอ I/O เล็ก ๆ จำนวนมาก ดีเลย์สะสมจะทำให้การตอบสนองแย่ลงมาก แนะนำให้รวมคำขอให้ใหญ่ขึ้นและน้อยครั้งลง
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: การออกแบบการซิงก์
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (อินพุตดีเลย์)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง