Discord ลดทราฟฟิก WebSocket ลง 40% ได้อย่างไร

 (discord.com)
23 คะแนน โดย GN⁺ 2024-09-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อไคลเอนต์เชื่อมต่อกับ Discord ก็จะได้รับอัปเดตแบบเรียลไทม์เกี่ยวกับสิ่งที่กำลังเกิดขึ้นผ่านบริการที่เรียกว่า "Gateway"
  • ตั้งแต่ปลายปี 2017 การเชื่อมต่อ Gateway ของไคลเอนต์ถูกบีบอัดด้วย zlib ทำให้ขนาดข้อความเล็กลงได้ตั้งแต่ 2 ถึง 10 เท่า
  • Zstandard (zstd) มีอัตราการบีบอัดสูงกว่า zlib ใช้เวลาบีบอัดสั้นกว่า และรองรับฟีเจอร์ dictionary ที่ช่วยลดแบนด์วิดท์ได้เพิ่มเติม
  • ผลการทดสอบ zstd ในปี 2019 ไม่ได้ออกมาดีนัก แต่ทีมมองว่ายังควรลองอีกครั้ง

การสตรีมด้วย Zstd

  • เดิม zlib ใช้การบีบอัดแบบสตรีมมิง แต่ zstd ยังไม่ได้ใช้
  • ในเพย์โหลดขนาดเล็ก zstd ทำงานได้แย่กว่า zlib
  • ทีมได้ fork ezstd ซึ่งเป็น zstd binding สำหรับ Elixir แล้วเพิ่มความสามารถด้านสตรีมมิงเข้าไป
  • หลังเปลี่ยนมาใช้การสตรีมด้วย zstd ก็พบว่าดีขึ้นอย่างมากทั้งด้านอัตราการบีบอัดและความเร็วเมื่อเทียบกับ zlib แบบสตรีมมิง

ความพยายามในการปรับแต่ง

การจูน

  • ปรับพารามิเตอร์การบีบอัดของ zstd เช่น chainlog, hashlog, windowlog เพื่อสร้างสมดุลระหว่างการใช้หน่วยความจำกับเวลาที่ใช้บีบอัด

Zstd Dictionary

  • ทีมพยายามใช้งานฟีเจอร์ dictionary ของ zstd เพื่อเพิ่มอัตราการบีบอัด แต่ผลลัพธ์มีจำกัด
  • จึงตัดสินใจไม่ใช้งาน เพราะความซับซ้อนของการใช้ dictionary สูงกว่าประโยชน์ที่ได้รับ

อัปเกรดบัฟเฟอร์

  • มีการทำ feedback loop เพื่ออัปเกรดบัฟเฟอร์ของ zstd โดยใช้หน่วยความจำส่วนเกินในช่วงเวลาที่มีการใช้งานต่ำ
  • แต่อัตราการอัปเกรดต่ำกว่าที่คาดไว้ และแม้จะพยายามปรับปรุงด้วยการจูนการตั้งค่า allocator ของ BEAM ก็ยังเห็นว่าประโยชน์ไม่คุ้มกับความซับซ้อน จึงยกเลิกแนวทางนี้

การพัฒนาและการปล่อยใช้งาน

  • เนื่องจาก zstd ช่วยลดการใช้แบนด์วิดท์ได้มาก จึงตัดสินใจนำไปใช้ไม่เฉพาะบนมือถือแต่รวมถึงเดสก์ท็อปด้วย
  • ทีมค้นหา zstd binding ที่เหมาะกับแต่ละแพลตฟอร์ม เช่น Java, Objective-C, Rust และค่อย ๆ ทยอยเปิดใช้งานตลอดหลายเดือน

ผลลัพธ์เพิ่มเติม: Passive Sessions V2

  • ระหว่างการนำ zstd มาใช้ ทีมค้นพบว่าข้อความ passive_update_v1 กินแบนด์วิดท์ของ Gateway มากกว่า 30%
  • จึงนำ passive_update_v2 มาใช้ ซึ่งส่งเฉพาะ channel/member ที่เปลี่ยนแปลง ทำให้สัดส่วนแบนด์วิดท์ส่วนนี้ลดจาก 35% เหลือ 5%

การประหยัดครั้งใหญ่

  • การรวมกันของ Passive Sessions v2 และ zstd ทำให้แบนด์วิดท์ Gateway ที่ไคลเอนต์ใช้งานลดลงเกือบ 40%
  • การค้นพบโอกาสในการเพิ่มประสิทธิภาพโดยไม่ตั้งใจครั้งนี้ แสดงให้เห็นถึงความสำคัญของการมีระบบวัดผลที่เหมาะสมและการวิเคราะห์กราฟด้วยมุมมองเชิงวิพากษ์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-09-23
ความคิดเห็นจาก Hacker News

  • มีคำบ่นเกี่ยวกับปัญหาที่ Discord ใช้เวลาเปิดทำงาน 20-30 วินาที

    • ตั้งคำถามว่าทำไมถึงยังเปิดช้าแม้บน PC ราคา $5000
    • เปรียบเปรยเหมือนกับว่ามีการคอมไพล์ไคลเอนต์ใหม่เป็นแบบ single-core ทุกครั้ง

  • ดูเหมือนว่าจะโฟกัสไปที่อัตราการบีบอัดและการลดแบนด์วิดท์เครือข่าย

    • ไม่มีการพูดถึงเวลา CPU หรือการปรับปรุงที่ผู้ใช้จริงวัดผลได้
    • ตอนบริษัทเคยพยายามทำอะไรคล้ายกัน ประสิทธิภาพกลับแย่ลงเพราะโอเวอร์เฮดจากการบีบอัด/คลายบีบอัด

  • แนวทางการบีบอัดแบบอาศัยพจนานุกรมโดยใช้ JSON และ Erlang ETF น่าสนใจ

    • เป็นวิธีที่เลือกแทนการย้ายไปใช้ระบบอิงสคีมาอย่าง Cap'n Proto หรือ Protobufs
    • สนใจ benchmark ของ Zstandard และ LZ4
    • สำหรับข้อมูลสตรีมมิง overlay/HUD ของโดรน เคยใช้ LZ4 และสามารถทำการบีบอัดใกล้เคียงกันที่ความเร็วสูงได้ด้วยพจนานุกรมที่สร้างจากเครื่องมือพจนานุกรมของ Zstd

  • น่าประหลาดใจที่การตอบกลับสำหรับการ bootstrap ทั่วไป (READY) มีขนาดเกิน 2MB

  • มีการพูดถึงเนื้อหาจริงของ dispatch PASSIVE_UPDATE_V1

    • แม้จะเปลี่ยนแค่ element เดียว ก็ยังส่งทุก channel, member หรือ voice member มาทั้งหมด
    • metric ที่พบระหว่างการทดลอง zstd แสดงพฤติกรรมที่น่าตกใจ
    • ตั้งคำถามว่าทำไมถึงไม่วิเคราะห์ metric ตั้งแต่แรก
    • ตั้งคำถามว่าทำไมถึงไม่ส่ง delta ตั้งแต่แรก

  • ไม่มีการพูดถึงความปลอดภัยต่อการโจมตีอย่าง compression oracle attack (BREACH)

    • เชื่อว่า Discord น่าจะพิจารณาเรื่องนี้แล้ว เพราะทุ่มเทกับการ rollout การบีบอัดมาก
    • เห็นว่าน่าจะเขียนรายละเอียดที่เจาะจงกว่านี้

  • มีปัญหาที่พอเปิดแท็บ Discord แล้วคอมพิวเตอร์จะช้าลง

  • ชอบมากที่อธิบายสิ่งที่ลองทำแล้วไม่ได้ผล

    • บทความที่อธิบายความพยายามที่ล้มเหลวมีน้อยลงเรื่อย ๆ แต่สิ่งนี้น่าสนใจและมีประโยชน์มาก

  • มีความเห็นว่า mIRC ทำได้ดีกว่า