ERPC

“ข้อมูล Solana มาช้าหรือไม่ครบ?” สิ่งที่ต้องตรวจสอบในระบบรับข้อมูล

“ข้อมูล Solana มาช้าหรือไม่ครบ?” สิ่งที่ต้องตรวจสอบในระบบรับข้อมูล

“ข้อมูล Solana มาช้าหรือไม่ครบ?” สิ่งที่ต้องตรวจสอบในระบบรับข้อมูล
คุณสมัครใช้สตรีม Solana Shreds ที่รวดเร็ว แต่แพ็กเก็ตกลับทยอยมาถึงเพียงเล็กน้อย Shreds ที่ได้รับสามารถพาร์สได้อย่างถูกต้อง แต่ชิ้นส่วนขาดหายไปมากจนไม่สามารถดึงธุรกรรมออกมาได้ ขณะที่ gRPC ทำงานได้บนเซิร์ฟเวอร์เดียวกัน จึงไม่แน่ใจว่าควรตรวจสอบจุดใดต่อ
นอกจากตรวจสอบฝั่งส่งแล้ว ควรพิจารณาเซิร์ฟเวอร์แอปพลิเคชันและศูนย์ข้อมูลที่โฮสต์เซิร์ฟเวอร์นั้นด้วย แม้ ERPC จะส่งต่อ Shreds ได้รวดเร็ว แต่ข้อจำกัดของ UDP ตามเส้นทางหรือคอขวดในการประมวลผลของเซิร์ฟเวอร์ฝั่งรับ อาจทำให้แอปพลิเคชันของคุณไม่ได้ประโยชน์จากความเร็วนั้น
การเลือกสตรีม Shreds จึงต้องพิจารณาตลอดทั้งเส้นทาง ทั้งวิธีที่แพ็กเก็ตมาถึงและวิธีที่แพ็กเก็ตเหล่านั้นกลายเป็นข้อมูลที่ใช้งานได้ คุณภาพเครือข่าย ระยะทาง และนโยบายการดำเนินงานของศูนย์ข้อมูล ยังเป็นเงื่อนไขร่วมที่ส่งผลต่อประสิทธิภาพของ Geyser Yellowstone gRPC รวมถึงทราฟฟิก RPC และ API ทั่วไป ตลอดจนการส่งธุรกรรมด้วย
เส้นทางเชิงแนวคิดจากการส่ง Shreds ที่รวดเร็วของ ERPC ผ่านศูนย์ข้อมูลฝั่งรับและเซิร์ฟเวอร์แอปพลิเคชันไปสู่ข้อมูลที่ใช้งานได้ โดยแยกข้อจำกัดของเครือข่ายออกจากคอขวดในการประมวลผลภายในเซิร์ฟเวอร์

บันทึกฝั่งส่งกับข้อมูลที่รับมาแล้วใช้งานได้เป็นคนละข้อเท็จจริง

ในคำขอรับการสนับสนุนที่ ERPC ได้รับเมื่อไม่นานมานี้ การวัดช่วงสั้น ๆ ที่ฝั่งส่งบันทึกได้ประมาณ 3,400–3,900 แพ็กเก็ต/วินาที ฝั่งรับรายงานว่ารับได้ประมาณ 13 แพ็กเก็ต/วินาที และไม่มีการประกอบข้อมูลสล็อตที่เสร็จสมบูรณ์
ตัวเลขเหล่านี้มาจากช่วงเวลาการวัดที่ต่างกัน และยังไม่ได้ยืนยันว่าวิธีวัดสามารถเปรียบเทียบกันได้ จึงไม่สามารถใช้สรุปอัตราการส่งถึงสำเร็จหรืออัตราการสูญหายได้ บันทึกฝั่งส่งเพียงอย่างเดียวไม่ได้พิสูจน์ว่าข้อมูลมาถึง และ ณ เวลาที่เขียนบทความนี้ ยังไม่สามารถระบุสาเหตุที่แน่ชัดได้
PPS เพียงไม่กี่พันก็ไม่ได้บ่งชี้ในตัวเองว่าเป็นภาระงานที่สูงผิดปกติสำหรับเซิร์ฟเวอร์ใช้งานทั่วไป ประเด็นที่ต้องตรวจสอบคือสิ่งที่เกิดขึ้นบนเส้นทางจริง ขีดจำกัดที่มีผลบังคับใช้ การกระจุกตัวของทราฟฟิกในช่วงเวลาสั้น ๆ วิธีจัดการการรับข้อมูล และสิ่งที่ตัวนับแต่ละตัววัด

อยู่แฟรงก์เฟิร์ตเหมือนกัน แต่เส้นทางเครือข่ายต่างกัน

ต้นทางสตรีมและเซิร์ฟเวอร์แอปพลิเคชันของคุณอาจอยู่ในแฟรงก์เฟิร์ตเหมือนกัน แต่ตั้งอยู่คนละศูนย์ข้อมูล ในการจัดวางเช่นนี้ ทราฟฟิกอาจออกจากศูนย์หนึ่ง ผ่านเครือข่ายภายนอก แล้วเข้าสู่อีกศูนย์หนึ่ง การระบุภูมิภาคเดียวกันไม่ได้ยืนยันว่าใช้สถานที่ ผู้ให้บริการเครือข่าย หรือชุดอุปกรณ์ระหว่างทางเดียวกัน
สำหรับสตรีมหรือบริการ RPC ของ ERPC และโฮสต์ ERPC VPS หรือ Bare Metal ที่จัดวางอยู่ในสถานที่เดียวกัน เซิร์ฟเวอร์ของบริการและเซิร์ฟเวอร์แอปพลิเคชันจะอยู่ในแร็กใกล้กัน และการสื่อสารระหว่างกันจะอยู่บนเครือข่ายภายใน นี่คือแนวคิดเบื้องหลัง Zero-Distance Communication ของ ERPC: ออกแบบตำแหน่งทางกายภาพและเส้นทางไปยังแอปพลิเคชันฝั่งรับร่วมกัน โดยพิจารณามากกว่าการเลือกเมืองเดียวกัน
การเปรียบเทียบเชิงแนวคิดระหว่างเส้นทางของศูนย์ข้อมูลคนละแห่งในแฟรงก์เฟิร์ตที่ผ่านเครือข่ายภายนอก กับการจัดวางของ ERPC ที่ใช้แร็กใกล้กันและเส้นทางภายใน ณ สถานที่เดียวกัน ครอบคลุมบริการ ERPC และเซิร์ฟเวอร์แอปพลิเคชันที่ใช้กับ Shreds, Yellowstone gRPC, RPC และการส่งธุรกรรม
การหลีกเลี่ยงเส้นทางอ้อมผ่านเครือข่ายภายนอกระหว่างบริการ ERPC กับเซิร์ฟเวอร์แอปพลิเคชันช่วยลดความยาวของเส้นทาง และลดโอกาสที่ช่วงเส้นทางนั้นจะได้รับผลจากความแออัดและการเปลี่ยนเส้นทางในเครือข่ายภายนอก เส้นทางที่สั้นร่วมกับทรัพยากรที่จำเป็นสำหรับการรับและประมวลผล เป็นพื้นฐานให้ได้รับประโยชน์จากสตรีมที่รวดเร็ว ควรตรวจสอบผลทั้งในขั้นที่แพ็กเก็ตมาถึงและขั้นการประมวลผลของแอปพลิเคชัน

สภาพเครือข่ายส่งผลต่อการสื่อสารทุกประเภท

ชิ้นส่วนที่ขาดหายทำให้เห็นปัญหาได้ชัดใน Shreds แต่คุณภาพของโครงสร้างพื้นฐานเดียวกันนี้ยังส่งผลต่อการรับข้อมูล คำขอ API และการส่งธุรกรรมในวงกว้างด้วย โปรโตคอลที่ใช้ทำให้อาการที่แอปพลิเคชันเห็นและจุดที่ควรวัดแตกต่างกัน
การสื่อสารจุดที่แสดงผลกระทบจากเครือข่ายสิ่งที่ควรตรวจสอบในแอปพลิเคชัน
Shreds / UDPแพ็กเก็ตสูญหายและล่าช้า รวมถึงการมาถึงของชิ้นส่วนที่จำเป็นต่อการประกอบข้อมูลกลับShreds ที่ถูกต้องและเวลาจนสามารถประกอบข้อมูลกลับได้
Geyser Yellowstone gRPCเวลารอการส่งซ้ำของ TCP ข้อมูลค้างสะสมในสตรีม และความล่าช้าเวลาจนได้รับและประมวลผลอัปเดตเดียวกัน
RPC, API และทราฟฟิกระหว่างบริการการเดินทางไปกลับของคำขอและคำตอบ และเวลารอระหว่างความแออัดเวลาตอบสนองและความผันผวนของเวลานั้น
การส่งธุรกรรมเส้นทางของคำขอไปยังโหนดฝั่งรับเวลาตั้งแต่คำขอส่งธุรกรรมจนถึงคำตอบของโหนด
การจัดวางใกล้กันและนโยบายการดำเนินงานที่เหมาะสมช่วยรองรับทราฟฟิกทุกประเภทข้างต้น ควรวัดเวลาตอบสนองของโหนดฝั่งรับแยกจากเวลาจนธุรกรรมถูกรวมเข้าในเชนและได้รับการยืนยันขั้นสุดท้าย

Gbps ไม่ได้บอกทุกอย่างเกี่ยวกับ PPS และทราฟฟิกที่พุ่งสูงเป็นช่วงสั้น ๆ

แบนด์วิดท์บอกปริมาณข้อมูลที่ส่งผ่านได้ในช่วงเวลาหนึ่ง ส่วน PPS บอกจำนวนแพ็กเก็ตที่ประมวลผลในแต่ละวินาที การเชื่อมต่ออาจยังมีแบนด์วิดท์เหลือ แต่ติดขีดจำกัดอัตราแพ็กเก็ตหรือข้อจำกัดที่ใช้กับ UDP ได้ เอกสารของผู้ให้บริการคลาวด์เองก็แยกขีดจำกัดแบนด์วิดท์กับ PPS เป็นข้อจำกัดคนละด้าน[1]
Shreds ไม่จำเป็นต้องมาถึงด้วยอัตราสม่ำเสมอ ทราฟฟิกที่พุ่งสูงในช่วงสั้น ๆ อาจสร้างแรงกดดันต่อคิวซึ่งค่าเฉลี่ยไม่แสดงให้เห็น หากแพ็กเก็ตสะสมเร็วกว่าที่อุปกรณ์เครือข่ายหรือฝั่งรับจะประมวลผลได้ แพ็กเก็ตที่เกินความจุของคิวอาจถูกทิ้ง[2]
สอบถามผู้ให้บริการโฮสติ้งเกี่ยวกับการรับ UDP อย่างต่อเนื่อง ทราฟฟิกที่พุ่งสูงเป็นช่วงสั้น ๆ ขีดจำกัด PPS และกฎที่ระบบป้องกัน DDoS ใช้ เป้าหมายคือการกำหนดเงื่อนไขที่เปิดรับทราฟฟิกที่จำเป็นได้อย่างปลอดภัย ไม่ใช่การปิดระบบป้องกันโดยไม่พิจารณา

gRPC ที่ทำงานได้ไม่ได้ยืนยันว่ารับ UDP ได้ปกติ

gRPC ที่ใช้ TCP และ Shreds แบบดิบที่ส่งผ่าน UDP ใช้กลไกการขนส่งข้อมูลต่างกัน TCP มีการส่งซ้ำและจัดลำดับ ส่วน gRPC แบบสตรีมมีการควบคุมการไหลที่คำนึงถึงความสามารถของฝั่งรับ UDP เองไม่ได้ส่งแพ็กเก็ตที่สูญหายซ้ำ และไม่ได้ทำให้ฝั่งส่งรอให้แอปพลิเคชันฝั่งรับประมวลผลตามทัน[3]
ดังนั้น การที่ gRPC ทำงานได้บนเซิร์ฟเวอร์จึงไม่ได้พิสูจน์ว่าเส้นทาง UDP หรือตัวรับทำงานถูกต้อง จำเป็นต้องตรวจสอบตัวกรองเฉพาะโปรโตคอล พอร์ต เส้นทางการส่ง และรูปแบบการทำงานของตัวรับแยกกัน ความล่าช้าในการประมวลผล gRPC อาจแสดงออกมาเป็นเวลารอหรือการตัดการเชื่อมต่อได้เช่นกัน
ธุรกรรม/วินาทีบน gRPC กับแพ็กเก็ต/วินาทีบน UDP วัดคนละหน่วยในคนละขั้นของการประมวลผล จึงไม่สามารถเปรียบเทียบโดยตรงเพื่อคำนวณปริมาณการส่งถึงหรืออัตราการสูญหายได้

จากแพ็กเก็ตที่มาถึงสู่ข้อมูลที่ใช้งานได้

เมื่อใช้ตัวรับแบบซ็อกเก็ต UDP มาตรฐาน แพ็กเก็ตที่มาถึงจะผ่าน NIC เคอร์เนล และบัฟเฟอร์รับของซ็อกเก็ต ก่อนถึงแอปพลิเคชัน หากประมวลผลตามไม่ทัน แพ็กเก็ตอาจถูกทิ้งหลังจากถึงโฮสต์แล้ว ตัวนับการรับของอินเทอร์เฟซ Linux รวมแพ็กเก็ตที่ถูกทิ้งในขั้นตอนถัดไปด้วย ดังนั้นตัวเลขการรับที่เพิ่มขึ้นเพียงอย่างเดียวจึงไม่ได้ยืนยันว่าข้อมูลถูกส่งถึงแอปพลิเคชัน[4]
คิวรับเพียงคิวเดียวหรือคอร์ CPU เพียงคอร์เดียวอาจมีภาระสูง แม้การใช้ CPU โดยรวมจะต่ำ ควรตรวจสอบคิวของ NIC การจัดสรรอินเทอร์รัปต์ และประสิทธิภาพต่อคอร์ ในแอปพลิเคชัน ควรแยกการรับข้อมูลออกจากงานขั้นถัดไปตามความเหมาะสม โดยย้ายงานพาร์สที่ใช้ทรัพยากรมากและการบันทึกล็อกที่มากเกินไปออกจากลูปรับข้อมูล บัฟเฟอร์รับที่ใหญ่ขึ้นอาจรองรับทราฟฟิกที่พุ่งสูงชั่วคราวได้ แต่ไม่สามารถแก้ปัญหาความสามารถในการประมวลผลที่ไม่เพียงพออย่างต่อเนื่อง[5]
Shreds เป็นชิ้นส่วนของข้อมูลบล็อก การแก้ไขข้อผิดพลาดแบบไปข้างหน้า (FEC) สามารถกู้ข้อมูลที่ขาดหายได้โดยใช้ Shreds ชนิด data และ coding จากกลุ่มเดียวกัน แต่การประกอบข้อมูลกลับยังต้องมีชิ้นส่วนมากเพียงพอ แพ็กเก็ตซ้ำที่เพิ่มขึ้นไม่สามารถทดแทนชิ้นส่วนที่ขาดหายไปได้[6]
ขึ้นอยู่กับรูปแบบการทำงาน ตัวรับอาจประกอบเอนทรีกลับจากชิ้นส่วนที่มีอยู่ได้ก่อนที่ทั้งสล็อตจะครบถ้วน[9] นอกจากจำนวนแพ็กเก็ตทั้งหมดแล้ว ควรวัด Shreds ที่ถูกต้องและไม่ซ้ำ ข้อมูลที่ประกอบกลับได้ และเวลาจนแอปพลิเคชันรับรู้เหตุการณ์ที่ต้องการด้วย

วัดแต่ละขั้นในช่วงเวลาเดียวกัน

ใช้ปลายทาง พอร์ต และช่วงเวลาการวัดให้ตรงกันทั้งสองฝั่ง การบันทึกขั้นตอนต่อไปนี้แยกกันจะช่วยจำกัดขอบเขตการตรวจสอบถัดไปให้แคบลง
จุดวัดสิ่งที่ควรบันทึกสิ่งที่ยืนยันได้
ฝั่งส่งบันทึกสำหรับปลายทางเป้าหมายและนิยามของตัวนับสังเกตการส่งในขั้นใด
จุดเข้าสู่โฮสต์ฝั่งรับการจับทราฟฟิก UDP เป้าหมาย สถิติ NIC และแพ็กเก็ตที่ตกหล่นระหว่างการจับมีทราฟฟิกให้เห็นมากเท่าใด ณ จุดสังเกตนั้น
OS และซ็อกเก็ตข้อผิดพลาด UDP แพ็กเก็ตที่ถูกทิ้งในบัฟเฟอร์รับ และการเปลี่ยนแปลงของคิวมีข้อมูลค้างสะสมในการรับภายในโฮสต์หรือไม่
การประกอบข้อมูล Shreds กลับShreds ที่ถูกต้องและไม่ซ้ำ การประกอบข้อมูลกลับสำเร็จ ข้อมูลที่ขาดหาย และข้อผิดพลาดแพ็กเก็ตให้ข้อมูลที่ต้องการได้หรือไม่
แอปพลิเคชันงานประมวลผลค้างสะสมและเวลาที่ตรวจพบเหตุการณ์เดียวกันความเร็วในการมาถึงส่งผลถึงแอปพลิเคชันหรือไม่
หากการจับแพ็กเก็ตพบแพ็กเก็ตเพียงเล็กน้อย ให้ตรวจสอบตัวกรอง อินเทอร์เฟซที่สังเกต การสูญหายระหว่างการจับ และแพ็กเก็ตที่ NIC ทิ้งก่อน ตัวนับของ OS บางตัวครอบคลุมทั้งโฮสต์หรือเนมสเปซเครือข่าย ควรตรวจสอบขอบเขตของตัวนับและเชื่อมโยงกับผลการวัดจากแอปพลิเคชันเป้าหมาย[4][5]
เปลี่ยนการตั้งค่าหลังจากระบุขั้นที่เป็นข้อจำกัดได้แล้ว การเพิ่มขนาดบัฟเฟอร์หรือริงเพียงอย่างเดียวอาจย้ายคอขวดไปจุดอื่นหรือเพิ่มเวลารอ เอกสารการตั้งค่าและการตรวจสอบตัวรับ ERPC ปัจจุบันอยู่ที่:
https://erpc.global/th/doc/shredstream/udp-forwarding/

เลือกนโยบายการดำเนินงานควบคู่กับเซิร์ฟเวอร์

Solana Foundation อธิบายถึงความสำคัญของการควบคุม NIC คอร์จริง ไดรเวอร์ และเครือข่ายสำหรับวาลิเดเตอร์ประสิทธิภาพสูง ข้อกำหนดสำหรับวาลิเดเตอร์เต็มรูปแบบเหล่านั้นไม่ควรถูกนำมาใช้ทั้งหมดกับตัวรับ Shreds ทุกตัว แอปพลิเคชันฝั่งรับต้องการการตั้งค่าที่เหมาะกับสตรีมและภาระงานประมวลผลของตนเอง[7]
การลดต้นทุนหรือการใช้พลังงานเป็นเป้าหมายการดำเนินงานที่สมเหตุสมผล ขณะเดียวกัน HFT และแอปพลิเคชันแบบเรียลไทม์ก็ต้องการการตอบสนองที่รวดเร็วของ CPU ความสามารถในการประมวลผลอย่างต่อเนื่อง และเวลารอบนเครือข่ายที่สั้น การตื่นจากสถานะประหยัดพลังงานอาจมีข้อแลกเปลี่ยนด้านความหน่วง[8]
นอกจากรุ่น CPU และจำนวนคอร์แล้ว ควรตรวจสอบวิธีแบ่งปันทรัพยากร การรับมือกับภาระงานต่อเนื่อง เงื่อนไขสำหรับทราฟฟิก UDP และเส้นทางเครือข่ายจริงด้วย

ERPC พิจารณาสตรีมและสภาพแวดล้อมฝั่งรับร่วมกัน

ERPC ดำเนินงานด้านการเลือกศูนย์ข้อมูลที่ใกล้โครงสร้างพื้นฐาน Solana เส้นทางเครือข่าย ฮาร์ดแวร์ และการตั้งค่าการดำเนินงาน โดยให้บริการ VPS และ Bare Metal ควบคู่กับ Shreds และ gRPC คุณสามารถเลือก VPS ให้เหมาะกับภาระงานประมวลผล และเปรียบเทียบกับ Bare Metal เมื่อต้องการทรัพยากรทางกายภาพที่ใช้ได้โดยเฉพาะ
ความเข้าใจในการตั้งค่าและการดำเนินงานของสภาพแวดล้อมที่เราให้บริการยังช่วยสนับสนุนการแก้ปัญหาทางเทคนิค เราสามารถเปรียบเทียบบันทึกฝั่งส่งกับผลการวัดฝั่งรับ และระบุการตรวจสอบที่ชัดเจนสำหรับเครือข่าย OS หรือแอปพลิเคชันได้ ในคำขอรับการสนับสนุนที่กล่าวถึงในบทความนี้ เราตรวจสอบผลการวัดฝั่งส่งและขอผลการวัดเพิ่มเติมจากฝั่งรับ
การประเมินสตรีม ตำแหน่งของตัวรับ และรูปแบบการพัฒนาแอปพลิเคชันร่วมกัน ช่วยให้ระบุได้ง่ายขึ้นว่าระหว่างบริการที่เลือกกับข้อมูลที่ต้องการยังขาดอะไรอยู่

เปรียบเทียบกับสภาพแวดล้อมปัจจุบันด้วยการคิดค่าบริการรายชั่วโมง

หากไม่แน่ใจเกี่ยวกับสภาพแวดล้อมฝั่งรับ ลองใช้เซิร์ฟเวอร์ ERPC VPS หรือ Bare Metal ที่คิดค่าบริการรายชั่วโมง และเปรียบเทียบโดยใช้สตรีมและแอปพลิเคชันเดียวกัน ตรวจสอบราคา ความพร้อมให้บริการ และเงื่อนไขการสั่งซื้อปัจจุบันในภูมิภาคที่ต้องการได้จากแดชบอร์ด
เริ่มจากการตั้งค่าที่มีให้ใช้งาน แล้วบันทึกจำนวนที่รับได้ ข้อมูลที่ประกอบกลับได้ งานประมวลผลค้างสะสม และเวลาที่ตรวจพบเหตุการณ์เดียวกัน เมื่อต้องเปรียบเทียบเวลาระหว่างโฮสต์ ให้ตรวจสอบความแม่นยำของการซิงโครไนซ์นาฬิกาด้วย ทดสอบซ้ำในเวลาที่ต่างกันและเปรียบเทียบว่าผลลัพธ์แตกต่างกันตรงส่วนใดของเส้นทาง ใช้ผลการวัดเหล่านั้นเลือกเซิร์ฟเวอร์และศูนย์ข้อมูลที่เหมาะกับแอปพลิเคชันของคุณ

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

เอกสารอ้างอิงทางเทคนิค

ถัดไป

ERPC เปิดตัว Solana Stream SDK v4.0.0 เพิ่มความเร็วในการประมวลผล UDP Shreds และการกู้คืนการเชื่อมต่อ gRPC

ข่าว

ERPC เปิดตัว Solana Stream SDK v4.0.0 เพิ่มความเร็วในการประมวลผล UDP Shreds และการกู้คืนการเชื่อมต่อ gRPC

ERPC เปิดตัว Solana Stream SDK v4.0.0 เพิ่มความเร็วในการประมวลผล UDP Shreds และการกู้คืนการเชื่อมต่อ gRPC

ERPC Edge ให้บริการ RPC แบบมัลติเชนสำหรับ 16 เชน รวมถึง Solana และ Ethereum ด้วยคีย์ RPC เดียว

ERPC Edge ให้บริการ RPC แบบมัลติเชนสำหรับ 16 เชน รวมถึง Solana และ Ethereum ด้วยคีย์ RPC เดียว

ERPC ขยาย Unlimited Endpoints: RPC ความเร็วสูงสำหรับ Solana, Ethereum และ Avalanche ภายใต้การสมัครใช้งานเดียว

ERPC ขยาย Unlimited Endpoints: RPC ความเร็วสูงสำหรับ Solana, Ethereum และ Avalanche ภายใต้การสมัครใช้งานเดียว