“เหตุใด latency ของ Solana ShredStream จึงเพิ่มขึ้นเรื่อย ๆ” สาเหตุและวิธีแก้ไข
ที่ ERPC เราได้รับคำถามจากลูกค้าที่ใช้สตรีมข้อมูลแบบเรียลไทม์ของ Solana อยู่บ่อยครั้งว่า “latency ของ ShredStream ค่อย ๆ เพิ่มขึ้นและหยุดทำงานในที่สุด”
ในบทความนี้ เราจะอธิบายสาเหตุหลักของปัญหานี้อย่างชัดเจน พร้อมเสนอวิธีแก้ไขที่เป็นรูปธรรมเพื่อเพิ่มประสิทธิภาพแอปพลิเคชันของคุณ
เหตุใด Latency ของ ShredStream จึงเพิ่มขึ้นเรื่อย ๆ
ปัจจุบัน ShredStream ส่งข้อมูลแบบเรียลไทม์เกือบทั้งหมดโดยไม่มี filter ดังนั้น หากความสามารถในการประมวลผลของ client ไม่เพียงพอ ข้อมูลจะสะสมและทำให้ latency ค่อย ๆ เพิ่มขึ้น
สาเหตุหลักมีดังนี้:
1. การประมวลผลด้วย Node.js หรือสภาพแวดล้อมแบบ Single-threaded
ในช่วงแรก ShredStream client สร้างขึ้นด้วย TypeScript และโปรโตคอล gRPC แต่เนื่องจากยังไม่ได้ใช้ filter การทำงานในสภาพแวดล้อมแบบ single-threaded อย่าง Node.js จึงถึงขีดจำกัดการประมวลผลอย่างรวดเร็ว ทำให้ latency เพิ่มขึ้นอย่างต่อเนื่อง
เราพบว่าปัญหานี้ไม่เกิดขึ้นเมื่อใช้ Rust client บนเครื่องเดียวกัน จึงยืนยันได้ว่าข้อจำกัดมาจากการประมวลผลแบบ single-threaded
วิธีแก้ไข: Multi-threading ด้วย NAPI-RS
เพื่อแก้ปัญหานี้ เราได้พัฒนาโซลูชันที่ใช้เทคโนโลยี NAPI-RS ซึ่งเปิดให้ประมวลผลแบบ multi-threaded ใน Rust ขณะที่ยังควบคุมจาก TypeScript ได้ โซลูชันนี้เรียกว่า Solana Stream SDK เป็นโอเพนซอร์สและเปิดให้ใช้งานสาธารณะ:
- GitHub: ValidatorsDAO/solana-stream
หากคุณใช้ Node.js หรือ TypeScript เราขอแนะนำอย่างยิ่งให้ใช้ SDK นี้ และหากต้องการประสิทธิภาพสูงสุด ควรพิจารณาภาษาแบบ native ที่รองรับ multi-threading เช่น Rust
2. ประสิทธิภาพเซิร์ฟเวอร์ไม่เพียงพอ (โดยเฉพาะ Clock Speed ของ CPU)
โดยทั่วไป แอปพลิเคชันสตรีมแบบเรียลไทม์ที่ใช้ Solana ShredStream สามารถทำงานได้เพียงพอบนเซิร์ฟเวอร์ที่มี 4 คอร์และ RAM 16GB อย่างไรก็ตาม clock speed ของ CPU มีความสำคัญอย่างยิ่ง ความเร็วสัญญาณนาฬิกาที่ต่ำอาจทำให้ latency ค่อย ๆ เพิ่มขึ้นได้
เซิร์ฟเวอร์ที่มุ่งเพิ่มกำไรสูงสุดมักใช้ CPU รุ่นเก่า หรือ CPU ที่มีหลายคอร์แต่ clock speed ต่ำ ตัวอย่างเช่น CPU AMD EPYC รุ่นที่ 4 ที่มีหลายคอร์ (เช่น รุ่น 84 คอร์) มักมี base clock ประมาณ 2.2GHz และมักใช้ turbo boost ได้ไม่เต็มประสิทธิภาพ เนื่องจากข้อกำหนดขั้นต่ำที่แนะนำสำหรับ Solana validator คือ 2.8GHz เราจึงขอแนะนำอย่างยิ่งให้ client ใช้ CPU ที่มี clock speed อย่างน้อยระดับนี้เช่นกัน
นอกจากนี้ ผู้ให้บริการ VPS มักใช้ “overcommitment” ซึ่งเป็นการแบ่งเซิร์ฟเวอร์จริงหนึ่งเครื่องออกเป็นเซิร์ฟเวอร์เสมือนหลายเครื่อง ในสภาพแวดล้อมที่มีการ overcommit การแย่งใช้ทรัพยากรกับผู้ใช้รายอื่นมักเกิดขึ้นในช่วงเวลาที่มีการใช้งานสูงสุดและส่งผลเสียต่อประสิทธิภาพ
วิธีแก้ไข: ใช้ VPS ที่มี CPU รุ่นล่าสุดและ Clock Speed สูง
ERPC ให้บริการเซิร์ฟเวอร์ VPS ที่ติดตั้ง CPU AMD EPYC รุ่นล่าสุด ซึ่งมี clock speed สูงสุด 4.15GHz เซิร์ฟเวอร์เหล่านี้ให้ประสิทธิภาพใกล้เคียงกับโซลูชัน bare-metal จึงเหมาะอย่างยิ่งกับเวิร์กโหลด Solana ที่ต้องใช้สตรีมข้อมูลแบบเรียลไทม์
ก่อนหน้านี้ไม่มีโซลูชัน VPS ที่มี clock speed สูง ทำให้ผู้ใช้ที่ต้องการประสิทธิภาพแบบเรียลไทม์จำเป็นต้องเลือกเซิร์ฟเวอร์ bare-metal แต่ VPS ของ ERPC ช่วยแก้ข้อจำกัดนี้
เราขอแนะนำ EPYC VPS ประสิทธิภาพสูงของเรา
โซลูชัน VPS ของ ERPC ปรับแต่งมาเพื่อการสตรีมข้อมูลแบบเรียลไทม์ของ Solana และได้รับเสียงชื่นชมอย่างสูงจากเทรดเดอร์ความถี่สูงและโครงการจำนวนมาก
โซลูชันเหล่านี้เหมาะอย่างยิ่งสำหรับ client ที่ต้องการประสิทธิภาพสูง แต่ไม่จำเป็นต้องใช้ทรัพยากรระดับเซิร์ฟเวอร์ bare-metal
เราขอเชิญชวนให้คุณทดลองใช้โซลูชัน VPS ของเรา
สำหรับการทดลองใช้ฟรีหรือการปรึกษาโดยละเอียด โปรดเยี่ยมชม Discord อย่างเป็นทางการของ Validators DAO:
- Discord อย่างเป็นทางการของ Validators DAO: https://discord.gg/C7ZQSrCkYR
ERPC ยังคงมุ่งมั่นวิจัยและพัฒนาอย่างต่อเนื่อง เพื่อตอบสนองความต้องการที่เปลี่ยนแปลงของคุณและสนับสนุนการเพิ่มประสิทธิภาพ
ขอขอบคุณสำหรับการสนับสนุนอย่างต่อเนื่อง
