คู่มือเกมแลค › ค้นหาตามอาการ

อินพุตดีเลย์: 76 สาเหตุและทีมที่ต้องแก้

เรียกอีกอย่างว่า: ตอบสนองช้า, input lag, กดแล้วไม่ได้ฟีล

เปิดพจนานุกรมอาการในฉบับหลักที่มีภาพ →

กดแล้วต้องรอสักพักกว่าผลจะออก ตัวภาพบนจออาจยังลื่นตามปกติ

กดปุ่มสกิลแล้ว 0.2–0.5 วินาทีกว่าจะออก การกระทำที่ต้องรอเซิร์ฟเวอร์ยืนยัน เช่น เก็บของ คุยกับ NPC หรือเทรด ช้าไปหมด

เวลาไปกลับ (ปิง) สูง หรือมีคิวสะสมอยู่ที่ใดที่หนึ่ง ให้ดูระยะทาง, คิวในเราเตอร์, Nagle (ฟีเจอร์ของ TCP ที่รวบแพ็กเก็ตเล็ก ๆ ไว้ส่งทีเดียว) และคิวของเซิร์ฟเวอร์ ถ้าปิงต่ำแต่ยังตอบสนองช้าตลอด ให้ดูฝั่ง PC ของเรา เช่น V-Sync หรือ FPS ต่ำ หรือดูว่าเกมออกแบบให้ทุกการกระทำต้องรอเซิร์ฟเวอร์ยืนยันหรือไม่ (บทรูปแบบการซิงก์)

สาเหตุที่ทำให้เกิดอาการนี้

L1 โปรเซสเกมฝั่งไคลเอนต์

• ภาระการเรนเดอร์ตัวละครจำนวนมาก: เมื่อคนหลายร้อยคนเข้ามาอยู่ในจอเดียว เช่น ศึกชิงปราสาทหรือเวิลด์บอส ลำพังต้นทุนการวาดภาพก็รับไม่ไหวแล้ว (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
• คอขวดการประมวลผลแพ็กเก็ตบนเมนเธรด: ถ้าประมวลผลแพ็กเก็ตที่รับมาได้แค่จำนวนที่กำหนดในแต่ละเฟรม แพ็กเก็ตที่ทะลักเข้ามาจะถูกเลื่อนไปเฟรมถัดไปเรื่อย ๆ (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
• V-Sync และคิวเรนเดอร์: ระหว่างที่ GPU เก็บเฟรมที่วาดเสร็จไว้ในคิวหลายเฟรม แล้วค่อยส่งออกตามรอบของจอ อินพุตจะช้าลง (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))

L2 OS และอุปกรณ์ฝั่งไคลเอนต์

• โหมดประหยัดพลังงานและ thermal throttling: โหมดแบตเตอรี่ของโน้ตบุ๊ก, โหมดประหยัดพลังงานของมือถือ และความร้อนของเครื่อง ทำให้ CPU และ GPU ช้าลง จุดสังเกตของความร้อนคือช่วงแรกปกติดี แล้วค่อยช้าลงหลังเล่นไปสักพัก (ภายนอก (ภายนอก))
• แอปอื่นในเครื่องเดียวกันแย่งแบนด์วิดท์: ถ้าการซิงก์ไฟล์ขึ้นคลาวด์, การดาวน์โหลดไฟล์ใหญ่ หรือแพตช์เกมกำลังทำงานบน PC เครื่องเดียวกัน แพ็กเก็ตเกมจะต้องรอในคิว (ภายนอก (ภายนอก))
• ดีเลย์จากจอ, อุปกรณ์อินพุต และ frame generation: ถ้าปิงปกติแต่การควบคุมรู้สึกหนืด อาจเป็นเพราะการประมวลผลภาพของทีวี, คอนโทรลเลอร์ไร้สาย หรือ frame generation กำลังเพิ่มดีเลย์ระหว่างอินพุตกับภาพบนจอ (ภายนอก (ภายนอก))

L3 เครือข่ายในบ้าน

• ช่องสัญญาณ Wi-Fi แออัด: ในที่ที่มีเราเตอร์หลายสิบตัวอย่างคอนโดหรืออพาร์ตเมนต์ ต้องแบ่งกันใช้ช่องสัญญาณเดียวกัน จึงต้องรอโอกาสส่ง (ภายนอก (ภายนอก))
• bufferbloat (คิวในเราเตอร์): เมื่อมีคนในบ้านอัปโหลดวิดีโอหรือดาวน์โหลดไฟล์ใหญ่ แพ็กเก็ตจะกองอยู่ในคิวของเราเตอร์ยาวเป็นหลายร้อย ms และแพ็กเก็ตเกมก็ต้องรอต่อท้าย (ภายนอก (ภายนอก))
• ดีเลย์จากการเปลี่ยนสถานะ RRC (โหมดประหยัดพลังงานของวิทยุมือถือ): ถ้าไม่มีการสื่อสารสักพัก มือถือจะลดการเชื่อมต่อวิทยุลงเป็นสถานะพลังงานต่ำ และเมื่อมีแพ็กเก็ตถัดไปต้องยกกลับขึ้นมาใหม่ จึงช้าลง (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))

L4 เส้นทางอินเทอร์เน็ต

• ความหน่วงในการแพร่สัญญาณ (ระยะทางจริง): แม้แต่แสงในสายไฟเบอร์ก็เดินทางได้แค่ประมาณ 200,000 กิโลเมตรใน 1 วินาที เซิร์ฟเวอร์ที่อยู่ไกลจะดีแค่ไหนก็ยังช้า (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• อินเทอร์เน็ตดาวเทียม (วงโคจรต่ำ/ค้างฟ้า): อินเทอร์เน็ตดาวเทียมต้องส่งสัญญาณขึ้นไปในอวกาศแล้วกลับลงมา ดาวเทียมวงโคจรค้างฟ้าแค่ช่วงขึ้นลงนี้ก็ใช้เวลาไปกลับเกิน 0.5 วินาทีแล้ว ส่วนดาวเทียมวงโคจรต่ำอย่าง Starlink ปกติเร็ว แต่ตอนที่ระบบจัดเส้นทางใหม่ ความหน่วงจะแกว่งและบางครั้งขาดไปชั่วครู่ (ภายนอก (ภายนอก))
• เส้นทางวิ่งอ้อม: เพราะสัญญาการเชื่อมต่อระหว่าง ISP แม้เซิร์ฟเวอร์จะอยู่ใกล้ แพ็กเก็ตก็ยังวิ่งอ้อมไปทางไกล (อินฟราเครือข่าย (ทีมอินฟรา))
• เคเบิลใต้น้ำ/วงจรต่างประเทศขัดข้อง: เมื่อเคเบิลใต้น้ำขาด ทราฟฟิกต้องอ้อมไปเส้นทางไกลหลายสัปดาห์ (นานสุดหลายเดือน) จนกว่าจะซ่อมเสร็จ และวงจรที่เหลืออยู่ก็แออัด (ภายนอก (ภายนอก))
• ISP จำกัดความเร็วและจัดการทราฟฟิก: ในแพ็กเกจที่ใช้ดาต้าเกินโควตาแล้ว หรือแพ็กเกจที่มีการจัดการทราฟฟิกบางประเภท แพ็กเก็ตจะถูกหน่วงหรือถูกทิ้ง (ภายนอก (ภายนอก))
• เชื่อมต่อผ่าน VPN/โปรแกรมลดปิง: เมื่อเปิด VPN หรือโปรแกรมลดปิง แพ็กเก็ตจะวิ่งผ่านเซิร์ฟเวอร์ตัวกลาง (relay) ของบริษัทนั้น ถ้าเซิร์ฟเวอร์ตัวกลางอยู่ไกลหรือแออัด ก็กลับยิ่งช้าลง (ภายนอก (ภายนอก))

L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์

• การอ้อมผ่านระบบป้องกัน DDoS และ false positive: เมื่อเบี่ยงทราฟฟิกไป scrubbing center เพื่อกันการโจมตี เส้นทางจะยาวขึ้น และบางครั้งระบบเข้าใจผิดว่าผู้เล่นปกติเป็นการโจมตีแล้วบล็อก (อินฟราเครือข่าย (ทีมอินฟรา))
• ลิงก์ของดาต้าเซ็นเตอร์เต็ม: ถ้าการแจกจ่ายแพตช์ การส่ง log หรือการสำรองข้อมูล ใช้ลิงก์เดียวกับเกม ลิงก์จะเต็ม (อินฟราเครือข่าย (ทีมอินฟรา))

L6 การ์ดเครือข่ายของเซิร์ฟเวอร์

• อินเทอร์รัปต์ของ NIC กระจุกที่คอร์เดียว: ถ้า NIC ส่งอินเทอร์รัปต์แจ้งว่าแพ็กเก็ตมาถึงไปที่คอร์ CPU เพียงคอร์เดียว คอร์นั้นจะกลายเป็นคอขวด (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• interrupt coalescing มากเกินไป: การรวบแพ็กเก็ตไว้แล้วแจ้งทีเดียวช่วยลดภาระ CPU แต่ก็ทำให้ช้าลงตามเวลาที่ใช้รวบ (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• แบนด์วิดท์ NIC เต็ม: ถ้าใช้การ์ด 1 Gbps หรือ 10 Gbps จนถึงขีดจำกัด transmit queue จะยาวขึ้น และสุดท้ายแพ็กเก็ตจะถูกทิ้ง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ดีเลย์จากการรอรวมแพ็กเก็ตของ GRO/LRO: เป็นฟีเจอร์ที่รวมหลายแพ็กเก็ตเป็นก้อนเดียวเพื่อลดภาระ CPU บางการตั้งค่าทำให้แพ็กเก็ตเกมขนาดเล็กต้องรอแพ็กเก็ตถัดไปที่จะรวมด้วยสักครู่ (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))

L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)

• ความหน่วงพุ่งจากการจัดการพลังงานของเซิร์ฟเวอร์ (C-state/การปรับความถี่): คอร์ CPU ที่ว่างจะเข้าโหมดประหยัดพลังงานระดับลึก (C-state) และลดความถี่ลงเพื่อประหยัดไฟ เมื่อแพ็กเก็ตหรือตัวจับเวลามาถึง ต้องใช้เวลาตื่นและเพิ่มความถี่ การประมวลผลแพ็กเก็ตเล็ก ๆ จึงมีดีเลย์เพิ่มขึ้น (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• ประสิทธิภาพเปลี่ยนไปหลังอัปเดต OS/เคอร์เนล/ไดรเวอร์/เฟิร์มแวร์: โค้ดเกมเหมือนเดิม แต่เซิร์ฟเวอร์ช้าลงตั้งแต่อัปเดต OS, เคอร์เนล, ไดรเวอร์ หรือเฟิร์มแวร์ การอัปเดตอาจเปลี่ยนค่าเริ่มต้น, scheduler, การป้องกันช่องโหว่ CPU (mitigations) และพฤติกรรมของไดรเวอร์ (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))

L8 ซ็อกเก็ตและโปรโตคอล

• อัลกอริทึม Nagle + delayed ACK: อัลกอริทึม Nagle ที่รวบรวมแพ็กเก็ตเล็กก่อนส่ง กับ delayed ACK ที่ส่ง ACK ช้า ทำงานประกบกัน ทุกครั้งที่เขียนข้อความแบ่งเป็นหลายส่วนจึงดีเลย์ 40–200 ms (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• slow start หลัง idle: เมื่อการเชื่อมต่อ idle ไปสักพัก TCP จะลด congestion window (ปริมาณที่ส่งได้ในครั้งเดียว) กลับลงมา พอต้องส่งข้อมูลก้อนใหญ่ขึ้นมากะทันหันจึงต้องแบ่งส่งหลายรอบ (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• อัตราการส่งดิ่งลงเพราะ congestion control: TCP มองว่าแพ็กเก็ตหายคือสัญญาณของความแออัด จึงลดอัตราการส่งลง 30–50% และตอบสนองแบบเดียวกันแม้แพ็กเก็ตหายเพราะ Wi-Fi (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• โครงสร้างแบบ blocking I/O: โครงสร้างที่เธรดทำอย่างอื่นไม่ได้ระหว่างรอซ็อกเก็ตตัวเดียว จะทำให้ทั้งระบบช้าลงเมื่อคนเพิ่มขึ้น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

L9 โปรเซสเกมฝั่งเซิร์ฟเวอร์

• ทิกเกินงบเวลา: ถ้างานในหนึ่งทิกเกินงบเวลา รอบทิกของเซิร์ฟเวอร์จะยืดออก และทั้งพื้นที่จะช้าลงหรือกระตุก (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ปริมาณ broadcast พุ่ง: ถ้าส่งการเคลื่อนไหวของผู้เล่นหนึ่งคนไปให้ทุกคนที่มองเห็น จะเกิดอัปเดตที่ต้องส่งเท่ากับจำนวนคนที่รวมตัวยกกำลังสอง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• พื้นที่ที่รันบนเธรดเดียวโหลดเกิน (hotspot): ในโครงสร้างที่แต่ละพื้นที่มีเธรดดูแลตัวเดียว ถ้าคนแห่ไปที่จุดเดียว คอร์ตัวนั้นตัวเดียวจะขึ้นไป 100% (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• การแย่งล็อก: ถ้าหลายเธรดรอล็อกตัวเดียวเพื่อเขียนข้อมูลเดียวกัน ต่อให้เพิ่มเธรด ก็ทำงานได้ทีละตัวเท่านั้น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ข้อความสะสมในคิว: ถ้าคำขอเข้ามาเร็วกว่าความเร็วในการประมวลผลจนกองในคิว คำขอที่อยู่ท้ายคิวจะถูกประมวลผลอีกหลายวินาทีต่อมาหรือถูกทิ้ง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ต้นทุนของ serialization และการบีบอัด: การแปลงข้อมูลที่จะส่งเป็นไบต์และบีบอัดก็ใช้ CPU เช่นกัน และเมื่อคนเยอะ ต้นทุนนี้จะพุ่งสูง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• thread pool หมด: ถ้า worker thread ที่ประมวลผลงานติดอยู่กับงานช้าทั้งหมด คำขอใหม่จะต้องรอไปเรื่อย ๆ อย่างไม่มีกำหนด (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• การต่อสู้ที่รุมเป้าหมายเดียว (เวิลด์บอส): ถ้าคนหลายร้อยคนตีบอสตัวเดียวพร้อมกัน การคำนวณของบอสตัวนั้นจะกระจุกที่จุดเดียว และข้อมูลการโจมตีจะถูกส่งให้ทุกคนที่มองเห็น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• spawn ทะลักเมื่อเข้าพื้นที่คนหนาแน่น: ถ้าเทเลพอร์ตเข้าเมืองที่คนแน่น เซิร์ฟเวอร์ต้องส่งรูปลักษณ์ อุปกรณ์ และสถานะของคนหลายร้อยคนที่เพิ่งมองเห็นไปพร้อมกันรวดเดียว (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• เอนทิตีสะสม (ไอเทม/ซัมมอนที่ไม่ถูกเก็บกวาด): ถ้าไอเทมที่ตกบนพื้นซึ่งควรหายไปแล้ว ซัมมอน และตัวจับเวลาที่จบแล้วไม่ถูกเก็บกวาดจนกองสะสม ยิ่งเปิดเซิร์ฟเวอร์ไว้นาน งานในแต่ละทิกก็ยิ่งเพิ่ม (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• แพตช์ทำให้รูปแบบทราฟฟิกเปลี่ยน: ถ้าคอนเทนต์ เอฟเฟกต์ หรือรายการที่ต้องซิงก์ใหม่ทำให้ขนาดและความถี่ของแพ็กเก็ตเพิ่ม เซิร์ฟเวอร์ที่เคยลื่นจะเริ่มชนขีดจำกัด MTU แบนด์วิดท์ และจำนวนแพ็กเก็ตหลังลงแพตช์ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

L11 ดิสก์

• fsync ทะลัก: ถ้าสั่งให้เขียนข้อมูลลงดิสก์ “แบบแน่นอน” แต่ละครั้งจะใช้เวลา 0.1 ms ถึงหลายสิบ ms แล้วแต่ดิสก์ และถ้ามาพร้อมกันมาก คิวจะยาวขึ้น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• burst credit ของดิสก์คลาวด์หมด: ดิสก์คลาวด์บางประเภทและเซิร์ฟเวอร์สเปกเล็กมี burst credit ที่ให้ทำงานเร็วกว่าประสิทธิภาพพื้นฐานได้ชั่วคราว ถ้าช่วงที่ยุ่งยาวนานจนเครดิตหมด ความเร็วจะตกลงกะทันหัน (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• ขีดจำกัด IOPS/คิวดิสก์อิ่มตัว: ถ้าคำขอเกินจำนวนที่ดิสก์ประมวลผลได้ใน 1 วินาที คิวจะยาวขึ้นและดีเลย์พุ่งสูง (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• งานสำรองข้อมูล/บีบอัด/สแกน: ถ้าการสำรองข้อมูลตอนเช้ามืด, การบีบอัด log หรือการสแกนความปลอดภัยยึดดิสก์ไว้ การอ่านและเขียนของเซิร์ฟเวอร์เกมจะล่าช้า (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• ดีเลย์จาก seek ของ HDD: HDD ต้องเลื่อนหัวอ่านไปบนจานแม่เหล็ก (seek) การอ่านเขียนข้อมูลที่กระจัดกระจายจึงใช้เวลาเกือบ 10 ms ต่อครั้ง (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))

L12 ฐานข้อมูล

• คิวรีที่ไม่มีอินเด็กซ์: ถ้าไม่มีอินเด็กซ์ การหาแถวที่ตรงเงื่อนไขต้องอ่านทั้งตาราง (full table scan) (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• แย่งล็อกบน hot row: ถ้าทุกคนพยายามแก้แถวเดียวกัน (โกดังกิลด์, ไอเทมฮิตในตลาดประมูล, ตัวนับของทั้งเซิร์ฟเวอร์) จะได้ล็อกทีละคนเท่านั้น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• เดดล็อกใน DB: ถ้าสองทรานแซกชัน (งาน DB ที่ประมวลผลเป็นชุดเดียว) ต่างรอแถวที่อีกฝ่ายล็อกไว้ DB จะบังคับยกเลิกฝั่งหนึ่ง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• connection pool หมด: จำนวนการเชื่อมต่อที่เปิดไว้กับ DB มีจำกัด ถ้าคิวรีที่ช้าถือครองการเชื่อมต่อไว้ คำขอที่เหลือต้องรอ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• checkpoint/log flush: จังหวะที่ DB เขียนส่วนที่เปลี่ยนแปลงในหน่วยความจำลงดิสก์รวดเดียวตามรอบ คิวรีจะช้าลง (อินฟรา DB (ทีมอินฟรา))
• cold cache (หลังรีสตาร์ตใหม่ ๆ): เมื่อรีสตาร์ต DB แคชในหน่วยความจำจะว่างเปล่า ช่วงหนึ่งข้อมูลทุกอย่างที่ดึงจึงต้องอ่านจากดิสก์ (อินฟรา DB (ทีมอินฟรา))
• คนแห่ล็อกอินและคิวรี N+1: ถ้าการโหลดตัวละครหนึ่งตัวต้องดึงข้อมูลแยกกันหลายสิบครั้ง ผู้เล่นหลายหมื่นคนที่ล็อกอินพร้อมกันจะกลายเป็นคิวรีหลายล้านคิวรี (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• งาน batch ขนาดใหญ่: ถ้ารันการสรุปอันดับ, การส่งจดหมายในเกมแบบรวดเดียว หรือการล้างข้อมูลเก่าระหว่างให้บริการ งานเหล่านี้จะยึดล็อกและดิสก์ไว้ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• แคชสแตมปีด: ถ้าแคชของข้อมูลยอดนิยมหมดอายุพร้อมกัน คำขอหลายพันรายการจะแห่ไปที่ DB พร้อมกัน (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ทรานแซกชันที่เปิดทิ้งไว้นาน: ถ้าทรานแซกชันหนึ่งเปิดทิ้งไว้นาน จะถือล็อกไว้ตลอด และ DB ล้างข้อมูลเวอร์ชันเก่า (purge) ไม่ได้ ทั้งระบบจึงค่อย ๆ ช้าลง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• คำสั่ง Redis ที่ช้า: Redis ประมวลผลคำสั่งทีละคำสั่ง คำสั่งที่ช้าเพียงคำสั่งเดียวจึงขวางทุกคำขอที่ตามมา (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• คิวรีช้าเพราะ query plan เปลี่ยน: โค้ดเหมือนเดิม แต่ถ้า DB เปลี่ยนวิธีประมวลผลคิวรีเดิม (query plan) คิวรีที่เมื่อวานใช้ 2 ms วันนี้อาจกลายเป็นหลายร้อย ms (อินฟรา DB (ทีมอินฟรา))
• ล็อกจากการเปลี่ยนสคีมา (DDL) ระหว่างให้บริการ: ถ้าเพิ่มคอลัมน์หรืออินเด็กซ์ให้ตารางระหว่างให้บริการ ล็อกที่ต้องใช้เพียงชั่วครู่ตัวเดียวอาจทำให้ทุกคำขอที่ใช้ตารางนั้นต้องรอ (อินฟรา DB (ทีมอินฟรา))

L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ

• การผ่านเกตเวย์/พร็อกซี: ถ้าวางเซิร์ฟเวอร์คั่นกลางระหว่างไคลเอนต์กับเซิร์ฟเวอร์เกม ทุกครั้งที่ผ่านจะมีเวลาประมวลผลเพิ่มขึ้น และเซิร์ฟเวอร์ตัวนั้นจะกลายเป็น single point of failure (จุดเดียวที่ล่มแล้วกระทบทั้งระบบ) (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ความล้มเหลวแบบลูกโซ่: เมื่อเซอร์วิสหนึ่งช้าลง เซิร์ฟเวอร์ที่เรียกใช้เซอร์วิสนั้นจะติดอยู่กับการรอคำตอบ จนฟีเจอร์ที่ไม่เกี่ยวข้องก็หยุดทำงานไปด้วย (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• การ deploy และรีสตาร์ต: ถ้ารีสตาร์ตเซิร์ฟเวอร์เพื่ออัปเดตโดยไม่ย้ายการเชื่อมต่อ ผู้เล่นที่อยู่บนเซิร์ฟเวอร์นั้นจะหลุด และการบันทึกข้อมูลก่อนปิดกับการเชื่อมต่อใหม่จะทะลักเข้ามาพร้อมกัน (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• มาโครและบอทมากเกินไป: บอทส่งคำขอถี่กว่าคนมาก จึงกินกำลังประมวลผลของเซิร์ฟเวอร์ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• matchmaking/การจัดรีเจียนผิดพลาด: ถ้าถูกจัดไปเซิร์ฟเวอร์ในรีเจียนที่ไกลแทนรีเจียนที่ใกล้ ผู้เล่นคนนั้นจะปิงสูงตลอดแม้เน็ตจะปกติ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

การออกแบบการซิงก์

• แสดงผลหลังเซิร์ฟเวอร์ตอบเท่านั้น (แบบ request-response): กดปุ่มแล้วไม่มีทั้งแอนิเมชันและเสียงจนกว่าคำตอบจากเซิร์ฟเวอร์จะมาถึง ปิงจึงกลายเป็นความเร็วในการตอบสนองโดยตรง (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
• โปรโตคอลที่ต้องไปกลับตามลำดับหลายรอบ (chatty): ถ้าการกระทำหนึ่งครั้งต้องไปกลับเซิร์ฟเวอร์หลายรอบตามลำดับ ปิงจะคูณตามจำนวนรอบนั้น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ไม่มีการกดสกิลล่วงหน้า: ถ้าต้องได้การยืนยันจากเซิร์ฟเวอร์ว่าสกิลก่อนหน้าจบแล้วจึงจะกดสกิลถัดไปได้ ทุกคอมโบจะมีเวลาไปกลับแทรกเข้ามา (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
• ช่วงเวลาตัดสินสั้นจนปิงกินหมด: ถ้าเวลาที่ต้องตอบสนอง เช่น การหลบ, การแพร์รี และการกัน สั้นเกินไป ปิงจะกินเวลานั้นไปจนเกิดการโจมตีที่หลบไม่ได้ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• lockstep ต้องรอผู้เล่นที่ช้าที่สุด: ในโครงสร้างที่ทุกคนคำนวณเทิร์นเดียวกันไปพร้อมกัน ถ้าอินพุตของคนหนึ่งช้า ทุกคนต้องรอ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• รอทิกซ้อนสองชั้น: ถ้าเก็บคำขอรอจนถึงทิกถัดไปแล้วจึงประมวลผล และส่งผลลัพธ์ในทิกถัดจากนั้นอีก ช่วงห่างระหว่างทิกจะถูกบวกเพิ่มสองครั้ง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

ปัญหาที่เกิดกับบางคนเท่านั้น

• ขนาดบัฟเฟอร์อินพุตของผู้เล่นแต่ละคน: ถ้าเซิร์ฟเวอร์เก็บอินพุตของแต่ละคนไว้เล็กน้อยแล้วดึงมาใช้ทิกละหนึ่งอัน คนอื่นจะเห็นลื่นไหล แต่จังหวะที่การกระทำของเจ้าตัวถูกยืนยันบนเซิร์ฟเวอร์จะช้าลงตามไปด้วย (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• เพื่อนในปาร์ตี้ที่ช้าหนึ่งคนกับกิมมิกบอส: ในกิมมิกเรดที่ทุกคนต้องตอบสนองพร้อมกันในจังหวะที่กำหนด การตอบสนองช้าของคนที่ช้าเพียงคนเดียวจะทำให้ทั้งปาร์ตี้ล้มเหลว (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ข้อมูลของตัวละครบางตัวใหญ่เกินไป: ตัวละครที่มีไอเทมหรือจดหมายสะสมหลายพันชิ้น หรือมีรายชื่อเพื่อน รายชื่อบล็อก และบัฟมากผิดปกติ ต้องโหลดตอนเชื่อมต่อ บันทึก และแจ้งคนรอบข้างมากกว่าคนอื่นหลายเท่า จึงช้าเฉพาะตัวละครนั้นโดยไม่เกี่ยวกับเน็ต (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• งบการส่ง/ลำดับความสำคัญต่อการเชื่อมต่อ: ถ้าเซิร์ฟเวอร์จำกัดปริมาณที่ส่งต่อการเชื่อมต่อและส่งสิ่งที่อยู่ใกล้ก่อน ฝั่งที่ถูกตั้งเพดานไว้ต่ำจะได้รับ NPC ที่อยู่ไกลช้าหรือไม่ได้รับเลย (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

ต้นเหตุของการส่งซ้ำใน TCP

• เครื่องเซิร์ฟเวอร์ฝั่งรับทิ้งแพ็กเก็ต: แพ็กเก็ตมาถึงเซิร์ฟเวอร์แล้ว แต่ถูกทิ้งเพราะ ring buffer ของ NIC (บัฟเฟอร์ที่พักแพ็กเก็ตที่มาถึงไว้ชั่วคราว) ล้น หรือคอร์ที่เคอร์เนลใช้ประมวลผลขาเข้าทำงานเต็ม (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• การส่งซ้ำโดยไม่จำเป็นเพราะความหน่วงพุ่ง: แพ็กเก็ตยังอยู่ครบและแค่มาถึงช้ามากชั่วครู่ แต่ถ้าความหน่วงนั้นนานกว่า RTO ฝั่งส่งจะตัดสินว่าหายแล้วส่งซ้ำ (ภายนอก (ภายนอก))
• fast retransmit โดยไม่จำเป็นเพราะแพ็กเก็ตสลับลำดับ: เมื่อแพ็กเก็ตสลับลำดับเพราะวิ่งผ่านหลายเส้นทางหรือลิงก์ที่รวมกัน ฝั่งรับจะแจ้งว่า “มีแพ็กเก็ตขาดหาย” ด้วย duplicate ACK และฝั่งส่งจะส่งแพ็กเก็ตที่ไม่ได้หายซ้ำ (อินฟราเครือข่าย (ทีมอินฟรา))
• ACK มาช้าหรือหาย (อัปโหลดเต็ม): ข้อมูลมาถึงเรียบร้อย แต่ถ้า ACK ที่บอกว่า “ได้รับแล้ว” ไปติดอยู่ในคิวอัปโหลดที่เต็มจนช้าหรือหาย ฝั่งส่งจะตัดสินว่าหายแล้วส่งซ้ำ (ภายนอก (ภายนอก))
• ค่า RTO ไม่เหมาะกับสภาพแวดล้อม: ถ้าลดค่าต่ำสุดของ RTO มากเกินไป แค่ช้านิดเดียวก็เกิดการส่งซ้ำโดยไม่จำเป็น ส่วนค่าเริ่มต้น (200 ms) ก็นานเกินไปสำหรับเกม ทุกครั้งที่แพ็กเก็ตหายจึงหยุดนาน (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))

ดูพจนานุกรมอาการในฉบับหลักที่มีภาพ