FAQ - ความหน่วงและภูมิภาค
คำถามเกี่ยวกับการเรียกเก็บเงิน แผนฟรี การชำระเงิน และ error 401 หรือ 429 อยู่ใน วิธีเริ่มต้น
คำถามที่ไม่เจาะจงเชนใด
คำถามเหล่านี้ครอบคลุมว่าระยะทาง ภูมิภาค ตำแหน่งเซิร์ฟเวอร์ shared endpoint หรือ dedicated endpoint และภาษาโปรแกรมที่ client ของคุณใช้ ส่งผลต่อความหน่วงอย่างไร
Q. ฉันต้องเลือกภูมิภาคหรือไม่?
เมื่อใช้ Edge RPC คุณไม่ต้องเลือกภูมิภาค แอปพลิเคชันที่เชื่อมต่อกับ edge.erpc.global จะถูกส่งต่อไปยังจุดเข้าใช้งานที่อยู่ใกล้บนเส้นทางเครือข่ายโดยอัตโนมัติ
สำหรับ Unlimited Endpoints ของ Solana, Ethereum และ Avalanche C-Chain คุณเลือกภูมิภาคเมื่อสั่งซื้อ โดยเลือกให้ใกล้กับที่ที่ระบบเทรดหรือ backend ของคุณทำงานอยู่ ตรวจสอบภูมิภาคที่เลือกได้ใน ERPC Web Dashboard เมื่อสั่งซื้อ
บน Solana ไม่มีภูมิภาคใดที่เหมาะกับทุกกลยุทธ์ เพราะบทบาท leader จะเปลี่ยนไปอยู่กับ validator ต่าง ๆ ตาม leader schedule ดูหัวข้อ Solana ด้านล่าง
Q. ฉันกำลังประสบปัญหาความหน่วงสูง เพราะอะไร?
คุณเข้าถึง endpoint จากตำแหน่งที่อยู่ใกล้ในทางกายภาพหรือไม่? ระยะทางส่งผลต่อความหน่วงอย่างมาก เราขอแนะนำให้เข้าถึงจากเซิร์ฟเวอร์ที่อยู่ใกล้กับ endpoint ที่ให้มา
ในทางทฤษฎี เครือข่ายของเราให้การเชื่อมต่อที่เร็วที่สุดผ่าน เซิร์ฟเวอร์ Bare Metal และ บริการ VPS ของเรา
Q. ความหน่วงเป็นอย่างไร?
ความหน่วงแตกต่างกันไปขึ้นอยู่กับวิธีการวัดและสภาพแวดล้อมการใช้งานเฉพาะของคุณ แทนที่จะมุ่งเน้นที่ค่าตัวเลขที่แน่นอน สิ่งสำคัญคือการทำให้แน่ใจว่าความหน่วงนั้นตรงกับความต้องการในการใช้งานจริงของคุณ
สำหรับ Solana คุณวัดความหน่วงได้ด้วยเครื่องมือโอเพนซอร์สสำหรับ TypeScript และ Rust ต่อไปนี้
Q. ทำไม dedicated endpoint ถึงเร็วกว่า?
shared endpoint ถูกใช้งานโดยลูกค้าหลายรายที่แชร์ทรัพยากรเดียวกัน เมื่อ traffic เพิ่มขึ้น ความหน่วงก็มักจะเกิดขึ้น ทรัพยากรของเซิร์ฟเวอร์มีขีดจำกัดทางกายภาพ และปริมาณงานที่รองรับได้นั้นมีจำกัด เมื่อมีคำขอจำนวนมากเกินไปเข้ามาในเวลาเดียวกัน ก็ต้องประมวลผลทีละรายการตามลำดับ ซึ่งทำให้เวลาตอบสนองช้าลง
แม้ว่าเราจะใช้มาตรการต่าง ๆ เพื่อปรับประสิทธิภาพให้เหมาะสมแม้บน shared endpoint แต่ด้วย dedicated endpoint คุณจะเป็นผู้ใช้ทรัพยากรเพียงรายเดียว นั่นหมายความว่าคุณจะไม่ได้รับผลกระทบจากผู้ใช้รายอื่นเลย จึงมั่นใจได้ถึงการตอบสนองที่เสถียรและรวดเร็วอย่างสม่ำเสมอ
นอกจากนี้ dedicated endpoint ยังมีตัวเลือกการสื่อสารแบบไม่ใช้ TLS เช่น HTTP โดยการข้าม TLS handshake (ประมาณ 20ms) ทำให้การสื่อสารเร็วยิ่งขึ้นเมื่อเทียบกับ HTTPS
Q. แผนไหนให้ประสิทธิภาพที่เร็วที่สุด?
โดยทั่วไปแล้ว แผนระดับสูงสุดของเราจะให้ประสิทธิภาพที่เร็วที่สุด เนื่องจากมี CPU ที่เหนือกว่า หน่วยความจำที่มากกว่า และการกำหนดค่าฮาร์ดแวร์ที่แข็งแกร่ง
เรายังมีโซลูชันที่ปรับแต่งได้หากคุณต้องการเซิร์ฟเวอร์ที่ทรงพลังยิ่งขึ้น แต่แผนมาตรฐานของเราก็ออกแบบมาเพื่อมอบอัตราส่วนราคาต่อประสิทธิภาพที่เหมาะสมที่สุด
เรามั่นใจในการมอบประสิทธิภาพระดับโลกในทุกระดับราคา หากคุณพบผู้ให้บริการที่เร็วกว่าในช่วงราคาเดียวกัน โปรดแจ้งให้เราทราบเพื่อที่เราจะได้ตรวจสอบและปรับปรุง
Q. ความหน่วงไม่เป็นไปตามที่ฉันคาดหวัง
ประสิทธิภาพอาจแตกต่างกันอย่างมากขึ้นอยู่กับภาษาโปรแกรมที่ใช้ โดยทั่วไปแล้ว การเปรียบเทียบความเร็วของภาษาจัดอันดับได้ดังนี้:
Rust > Go > TypeScript (JavaScript) > Python
ดูการเปรียบเทียบโดยละเอียดเพิ่มเติมได้จากแหล่งข้อมูลต่อไปนี้:
หากเป้าหมายของคุณคือประสิทธิภาพสูงสุด เราขอแนะนำอย่างยิ่งให้ใช้ Rust
Solana
คำตอบเหล่านี้อาศัยวิธีการทำงานของ Solana: บทบาท leader จะเปลี่ยนไปอยู่กับ validator ต่าง ๆ ตาม leader schedule ดังนั้นตำแหน่งของ validator จึงมีผลต่อการเลือกภูมิภาคของคุณ
Q. คุณแนะนำภูมิภาคไหน?
ไม่มีภูมิภาคใดที่ดีที่สุดอย่างถาวรเพียงภูมิภาคเดียว Solana เป็นเครือข่ายระดับโลก และบทบาท leader จะเปลี่ยนไปอยู่กับ validator ต่าง ๆ ตาม leader schedule ภูมิภาคที่มี validator มากกว่าและมี stake สูงกว่าจะมี leader slot บ่อยกว่า ซึ่งอาจช่วยให้ transaction land ได้เร็วขึ้น ข้อแลกเปลี่ยนคือ traffic ที่แข่งขันกันก็จะหนาแน่นอยู่ที่นั่นเช่นกัน ดังนั้นภูมิภาคที่มีคนใช้น้อยกว่าบางครั้งอาจให้ผลลัพธ์ที่ดีกว่า ขึ้นอยู่กับกลยุทธ์ของคุณ
ในทางปฏิบัติ ให้เริ่มต้นด้วยการเลือกภูมิภาคที่มี validator หนาแน่น เช่น Frankfurt หรือชายฝั่งตะวันออกของสหรัฐ เมื่อการมี leader slot อย่างสม่ำเสมอเป็นสิ่งสำคัญที่สุด หรือวางระบบของคุณไว้ใกล้ validator เป้าหมายที่เจาะจง เมื่อการทำงานผ่านเส้นทางที่สั้นที่สุดเป็นสิ่งสำคัญลำดับแรก ใช้ Validators Solutions เพื่อทำความเข้าใจการกระจายตัวของเครือข่าย Solana สาธารณะ จากนั้นใช้ ERPC Leader Slot API และการวัดผลจริงเพื่อตัดสินใจว่าการ deploy แบบใดเหมาะสม ระหว่างภูมิภาคเดียว สองภูมิภาค หรือทั่วโลก
Q. ฉันต้องการความหน่วงประมาณ 400ms หรือต่ำกว่านั้น
เพื่อให้ได้ความหน่วงภายในประมาณ 400ms โปรดพิจารณาประเด็นสำคัญเหล่านี้:
-
ทำความเข้าใจค่า Ping อย่างสมจริง: ค่า ping บ่งบอกถึงสภาวะในอุดมคติ และไม่ได้สะท้อนความหน่วงจริงในการสื่อสารแบบ streaming ซึ่งโดยทั่วไปจะมีความหน่วงประมาณ 5 เท่าของค่า ping เช่น ค่า ping 100ms ข้ามทวีปจะส่งผลให้เกิดความหน่วงจริงประมาณ 500ms ดังนั้นจึงต้องตั้งโครงสร้างพื้นฐานไว้ภายในภูมิภาคเดียวกันเพื่อให้ได้ความหน่วง ~400ms
- ค่า Ping อ้างอิงทั่วไป:
- เครือข่ายเดียวกัน: ~0.1ms
- การเชื่อมต่อระหว่างเครือข่ายแบบส่วนตัว (PNI): ~0.2ms
- ศูนย์ข้อมูลเดียวกัน: ~0.3ms
- เมืองเดียวกัน: ~1ms
- ประเทศใกล้เคียง: ~5–10ms
- ข้ามทวีป: ~100–300ms
- ค่า Ping อ้างอิงทั่วไป:
-
หลีกเลี่ยงกับดักของความหน่วงเฉลี่ย: validator ของ Solana กระจายตัวอยู่ทั่วโลกในเชิงภูมิศาสตร์ และ leader schedule จะเปลี่ยนแบบสุ่มในแต่ละ epoch การพึ่งพาความหน่วงเฉลี่ยเพื่อให้ได้ ~400ms นั้นไม่สามารถทำได้จริง แต่คุณควรติดตามตาราง validator ในภูมิภาคที่เจาะจงของคุณอย่างแม่นยำ เพื่อระบุ slot ที่มีความหน่วงต่ำที่สุด การจะได้ความหน่วงต่ำที่สุดอย่างสม่ำเสมอนั้นจำเป็นต้องมีโครงสร้างพื้นฐานครอบคลุมทุกภูมิภาคที่เกี่ยวข้อง ภายในภูมิภาคเดียวกัน การดึงข้อมูลสามารถเกิดขึ้นได้ในระดับหลายสิบมิลลิวินาที และการส่งข้อมูลทำได้ในเวลาเพียงไม่กี่มิลลิวินาที
-
ติดตาม Leader Schedule: ติดตามตาราง leader validator สำหรับภูมิภาคของคุณด้วย ERPC Leader Slot API (
getLeaderSlots) API นี้คืนค่าตาราง leader ที่กำลังจะมาถึง น้ำหนัก stake ของ epoch ปัจจุบัน ตำแหน่งทางภูมิศาสตร์โดยประมาณของ validator และค่า ping อ้างอิง ทำให้คุณระบุ slot ที่มีความหน่วงต่ำที่สุดซึ่งควรเล็งเป้าไว้ได้ตั้งแต่ก่อนที่ slot เหล่านั้นจะมาถึง ข้อมูลสาธารณะในรูปแบบแผนที่และ native RPC API มีประโยชน์สำหรับการมองเห็นเครือข่ายในภาพกว้าง แต่ยังไม่แม่นยำพอสำหรับการกำหนดจังหวะเวลาในการดำเนินการ Leader Slot API เติมเต็มช่องว่างนั้นด้วยความละเอียดที่จำเป็นสำหรับการตัดสินใจเรื่อง routing และการเทรด
ข้อมูลเครือข่าย Solana: Validators Solutions
Q. ฉันจะทำการเทรดแบบ zero-block (zero-slot) ได้อย่างไร?
การทำการเทรดแบบ zero-block (zero-slot) ให้สำเร็จต้องใช้กลยุทธ์ที่ซับซ้อนยิ่งขึ้น ดังนี้:
-
ระบุ Opportunity Zone: validator ของ Solana กระจายตัวอยู่ทั่วโลก และเป็นไปไม่ได้ในเชิงกายภาพที่จะได้ความหน่วงที่เหมาะสมที่สุดสำหรับทุก slot ดังนั้นให้ติดตามตาราง leader ของ validator ในภูมิภาคที่โครงสร้างพื้นฐานของคุณตั้งอยู่ และระบุ opportunity zone ที่เอื้อประโยชน์มากที่สุด การ deploy โครงสร้างพื้นฐานในหลายภูมิภาคก็อาจเป็นข้อได้เปรียบเช่นกัน ตัวอย่างเช่น Frankfurt เป็นภูมิภาคสำคัญเนื่องจากมีความหนาแน่นของ validator สูง จึงได้รับเลือกเป็น leader บ่อยขึ้นและมีโอกาสในการเทรดมากขึ้นใช้ ERPC Leader Slot API (
getLeaderSlots) เพื่อดูตาราง leader ที่กำลังจะมาถึง น้ำหนัก stake ของ epoch ปัจจุบัน ข้อมูลตำแหน่งทางภูมิศาสตร์โดยประมาณของ validator และค่า ping อ้างอิง ด้วยความแม่นยำที่สูงกว่าแหล่งข้อมูลสาธารณะในรูปแบบแผนที่หรือ native RPC API อย่างมาก ข้อมูลนี้ช่วยให้คุณกำหนดขอบเขตของ opportunity zone ได้ก่อนที่ slot จะมาถึง และดำเนินการเทรดด้วยความหน่วงที่เกือบเป็นศูนย์ -
ใช้ Dedicated Node: หากคุณแข่งขันได้ยาก ให้พิจารณา deploy dedicated node โหนดแบบใช้ร่วมกันจะมีความหน่วงเนื่องจาก traffic จากผู้ใช้รายอื่น จึงไม่แนะนำ ยิ่งไปกว่านั้น การวาง dedicated node ของคุณไว้ในเครือข่ายเดียวกันกับแอปพลิเคชันของคุณจะช่วยลดความหน่วงของเครือข่ายได้อย่างมีนัยสำคัญและปรับประสิทธิภาพให้เหมาะสมที่สุด
Q. อันไหนเร็วที่สุด: WebSockets, gRPC หรือ Shreds?
ผลตอบรับจากลูกค้าจำนวนมากค่อนข้างสอดคล้องกัน โดยลำดับประสิทธิภาพเป็นดังนี้:
Shreds > gRPC > WebSockets
หากคุณพบผลลัพธ์หรือเงื่อนไขที่แตกต่างออกไป โปรดแจ้งให้เราทราบ
Q. RPC (gRPC, Shreds) นี้เร็วกว่าเจ้าอื่นไหม?
เราออกแบบทุกระดับราคาโดยให้ความสำคัญกับความเร็ว และยินดีให้มีการวัดเปรียบเทียบแบบเคียงข้างกับผู้ให้บริการรายอื่นใดก็ตาม ผลลัพธ์อาจแตกต่างกันตามภูมิภาค ตามการใช้ shared endpoint หรือ dedicated endpoint ตามโปรโตคอลที่ใช้ (WebSockets, gRPC หรือ Shreds) และตามภาษาโปรแกรมที่ client ของคุณใช้
หากคุณพบว่าบริการของเราช้ากว่า โปรดแจ้งเงื่อนไขที่เจาะจงและคู่แข่งที่คุณนำมาเปรียบเทียบให้เราทราบผ่าน ERPC Web Dashboard เราจะหาสาเหตุและปรับปรุงความเร็วให้ดียิ่งขึ้น