FAQ - Solana Shreds
Q. Output ของ Shreds / getBlock อยู่ ๆ ก็ดูเสียหาย หรือคืนค่า -32015 — มีอะไรเปลี่ยนไป?
Solana Transaction v1 (SIMD-0385) เริ่มมีผลบน Solana mainnet เมื่อวันที่ 15 กันยายน 2026 ที่ epoch 1035 โดย wire layout ของ transaction แบบ v1 จะขึ้นต้นด้วย byte นำหน้าเวอร์ชัน
0x81 ลายเซ็นจะอยู่หลัง message และไม่มี length prefix แบบ legacy อีกต่อไปหากคุณถอดรหัส entry ของ ShredStream หรือ UDP Forwarding ด้วยตัวเอง ตัวถอดรหัส
bincode หรือ solana-entry ที่ต่ำกว่าเวอร์ชัน 4.2 จะอ่าน byte 0x81 นี้ผิดเป็นจำนวนลายเซ็น ซึ่งจะแสดงออกมาเป็น EOF error, compact-length overflow หรือ error "invalid message version" ผู้ใช้ Geyser gRPC ที่ deserialize raw transaction ด้วย crate ก่อน 4.2 ก็เจอปัญหาเดียวกัน การเรียก RPC getBlock และ getTransaction ด้วย maxSupportedTransactionVersion: 0 จะคืนค่า -32015 Transaction version (1) is not supported by the requesting client ส่วน getTransactionsForAddress ในโหมด full จะรายงาน error เดียวกันในทุกแถวที่ได้รับผลกระทบ หากคุณอ่าน JSON response ที่ parse แล้วของ ERPC โดยตั้งค่า version 1 อยู่แล้ว คุณจะไม่ได้รับผลกระทบตั้งค่า
maxSupportedTransactionVersion เป็น 1 ใน options object ซึ่งเป็นพารามิเตอร์ตัวที่สองของ getBlock และ getTransaction รวมถึงใน options ของ getTransactionsForAddress ด้วย:json
อัปเกรด Solana Stream SDK เป็น
2.0.0: solana-stream-sdk สำหรับ Rust บน crates.io หรือ @validators-dao/solana-stream-sdk และ @validators-dao/solana-shreds-client บน npm และอัปเกรด @validators-dao/solana-entry-decoder แยกต่างหากเป็น 2.5.0 ทั้งนี้ 1.4.0 และ entry-decoder 2.4.0 ไม่รองรับ v1 ส่วนตัวถอดรหัส Rust ที่เขียนเองควรย้ายไปใช้ solana-entry 4.2.x- คู่มือการย้ายระบบ
- บันทึกการเปลี่ยนแปลงของ SDK 2.0.0
- Repository ของ Solana Stream SDK
- SIMD-0385: ข้อเสนอ Transaction v1
- การอัปเกรด Solana: Larger Transaction Sizes
- เอกสาร Solana RPC: getBlock
- เอกสาร Solana RPC: getTransaction
- เอกสาร ERPC: เริ่มต้นใช้งาน ShredStream
- เอกสาร ERPC: เริ่มต้นใช้งาน Geyser gRPC
- เอกสาร ERPC: RPC
Q. โหนดของคุณตั้งอยู่ในภูมิภาคใดบ้าง?
ปัจจุบันเราให้บริการโหนดในภูมิภาคต่อไปนี้:
- Frankfurt (FRA)
- Amsterdam (AMS)
- London (LON)
- Dublin (DUB)
- New York (NY)
- Chicago (CHI)
- Salt Lake City (SLC)
- Tokyo (TY)
- Singapore (SGP)
- Sydney (SYD)
ERPC วัดความหน่วงของเครือข่ายจริงโดยอ้างอิงจากเส้นทาง routing จริง และเลือกภูมิภาคที่มีความหน่วงต่ำที่สุดโดยอัตโนมัติ แทนที่จะอาศัยระยะทางในแนวเส้นตรง วิธีนี้ไม่เพียงช่วยลดความหน่วงให้กับผู้ใช้แต่ละราย แต่ยังเพิ่มประสิทธิภาพโดยรวมของเครือข่าย และเสริมความแข็งแกร่งของ ERPC ในระดับโลกต่อการโจมตีที่อาจเกิดขึ้นด้วย
หากสภาพแวดล้อมของคุณไม่ได้เลือกภูมิภาคที่เหมาะสมที่สุดโดยอัตโนมัติ โปรดติดต่อเราผ่าน ERPC Web Dashboard
ERPC Web Dashboard: https://dashboard.erpc.global/th
Q. ค่าความหน่วงแสดงเป็น 9999ms และระบบเลือกภูมิภาคที่ไม่เหมาะสม ควรทำอย่างไร?
สำหรับการเลือกภูมิภาคของ Shreds นั้น ERPC จะส่งโพรบวัดเวลาแฝง ICMP ไปยัง IP ที่ลงทะเบียนของคุณจากโฮสต์พร็อกซีที่แสดงด้านล่าง อนุญาตคำขอ ICMP echo ขาเข้าจาก IP ต้นทางที่แสดงไว้ทั้งหมด หากถูกไฟร์วอลล์ (ufw, ไฟร์วอลล์ระบบคลาวด์, กลุ่มความปลอดภัย เป็นต้น) บล็อก ค่าที่วัดได้อาจเป็น
9999ms และอาจมีการเลือกภูมิภาคที่ไม่เหมาะสม IP หลายรายการในภูมิภาคเดียวกันมาจากโฮสต์โพรบคนละเครื่อง และจำเป็นต้องอนุญาตทั้งหมดเลือก Far Point แล้ว
Far Point ของ Shared Shreds เป็นตัวเลือกสำรองที่มีความจุจำกัด แต่ละ endpoint รองรับ stream ที่พร็อกซีพร้อมกันได้สูงสุด 32 รายการรวมลูกค้าทั้งหมด ไม่ใช่ 32 สล็อตต่อลูกค้า การสตรีมจะมีประสิทธิภาพสูงสุดเมื่อ subscriber ทำงานใกล้กับ Shreds endpoint ที่เลือก stream ระยะไกลจะใช้การเชื่อมต่อร่วม หน้าต่างควบคุมโฟลว์ และความจุ egress เป็นเวลานานกว่า เพื่อช่วยให้สภาพแวดล้อมแบบใช้ร่วมกันตอบสนองได้ดี โปรดอนุญาต IP ต้นทางของโพรบ ICMP ระดับภูมิภาคทั้งหมดที่แสดงไว้ แล้วเรียกใช้การเลือกภูมิภาคอีกครั้ง สำหรับการใช้งานต่อเนื่อง โปรดพิจารณา ERPC VPS ใกล้กับ endpoint ที่เลือก ส่วน UDP Forwarding มีให้เลือกทั้ง Standard และ Premium ไม่ว่าจะใช้แบบใด คุณจะเลือกภูมิภาคของ UDP Forwarding ใน ERPC Web Dashboard และ Shreds ดิบจะส่งมาทาง UDP ถึงที่อยู่ IPv4 สาธารณะและพอร์ตที่คุณกำหนดค่าไว้
ใช้ ERPC VPS ใกล้ endpoint นี้ · เปรียบเทียบตัวเลือก UDP Forwarding
อ่านคู่มือเริ่มต้นใช้งาน Solana Shreds
Q. ฉัน allowlist IP แล้ว แต่ยังเชื่อมต่อไม่ได้ ควรตรวจสอบอะไร?
ใช้ HTTPS endpoint แบบเข้ารหัสที่เลือกใน Dashboard โดย HTTPS ใช้ port 443 ส่วน HTTP บน port 80 ยังคงเป็นตัวเลือกความหน่วงต่ำที่ไม่เข้ารหัส
ทั้ง HTTPS และ HTTP ใช้ allowlist ของ IP ที่ลงทะเบียนไว้ชุดเดียวกัน ใช้ endpoint ที่เลือกใน Dashboard: HTTPS ที่ 443 หรือ HTTP ที่ 80
- HTTPS endpoint: ใช้ endpoint ที่เลือกใน Dashboard บน port 443
- HTTP endpoint: ใช้ endpoint ที่เลือกใน Dashboard บน port 80
- ใช้ URL ที่แสดงใน Dashboard ในรูปแบบ
https://หรือhttp://
การยืนยันตัวตนอ้างอิงจาก IP address ที่ลงทะเบียนไว้ อย่าเพิ่ม header
x-token, token หรือ Authorization เว้นแต่หน้าของผลิตภัณฑ์นั้นจะระบุไว้อย่างชัดเจนให้เพิ่มQ. ก่อนหน้านี้ฉันใช้แค่ WebSocket หรือ Geyser gRPC (YellowStone) มีตัวอย่างให้ดูไหม?
มี คุณสามารถเริ่มทดสอบการเชื่อมต่อ Shreds และพัฒนาแอปพลิเคชันได้อย่างรวดเร็วโดยใช้ SLV
ดูรายละเอียดได้จากคู่มือต่อไปนี้:
Q. ฉันสามารถลงทะเบียน IP address สองรายการได้ไหม?
คุณสามารถใช้หนึ่ง endpoint ต่อหนึ่ง subscription หากคุณต้องการใช้ IP address สองรายการ คุณจะต้องสมัครสอง subscription แยกกัน
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. ฉันสามารถใช้ endpoint ที่เจาะจงได้ไหม?
เพื่อรักษาสภาพแวดล้อมที่มีความหน่วงต่ำ ระบบของเราจะเลือกโหนดที่ใกล้ที่สุดที่พร้อมใช้งานโดยอัตโนมัติ หากคุณต้องการใช้ endpoint ที่เจาะจง เราขอแนะนำให้เช่าเซิร์ฟเวอร์ที่อยู่ใกล้ที่สุดกับ endpoint นั้น
Q. ทำไม dedicated endpoint ถึงเร็วกว่า?
shared endpoint ถูกใช้งานโดยลูกค้าหลายรายที่แชร์ทรัพยากรเดียวกัน เมื่อ traffic เพิ่มขึ้น ความหน่วงก็มักจะเกิดขึ้น ทรัพยากรของเซิร์ฟเวอร์มีขีดจำกัดทางกายภาพ และปริมาณงานที่รองรับได้นั้นมีจำกัด เมื่อมีคำขอจำนวนมากเกินไปเข้ามาในเวลาเดียวกัน ก็ต้องประมวลผลทีละรายการตามลำดับ ซึ่งทำให้เวลาตอบสนองช้าลง
แม้ว่าเราจะใช้มาตรการต่าง ๆ เพื่อปรับประสิทธิภาพให้เหมาะสมแม้บน shared endpoint แต่ด้วย dedicated endpoint คุณจะเป็นผู้ใช้ทรัพยากรเพียงรายเดียว นั่นหมายความว่าคุณจะไม่ได้รับผลกระทบจากผู้ใช้รายอื่นเลย จึงมั่นใจได้ถึงการตอบสนองที่เสถียรและรวดเร็วอย่างสม่ำเสมอ
นอกจากนี้ dedicated endpoint ยังมีตัวเลือกการสื่อสารแบบไม่ใช้ TLS เช่น HTTP โดยการข้าม TLS handshake (ประมาณ 20ms) ทำให้การสื่อสารเร็วยิ่งขึ้นเมื่อเทียบกับ HTTPS
Q. ราคาขายจะถูกปรับขึ้นไหมหลังจากที่ฉันสมัครแล้ว?
ตราบใดที่ subscription ของคุณยังใช้งานอยู่ ราคาขายที่คุณล็อกไว้ตอนสมัครจะยังคงมีผลต่อไป สภาพแวดล้อมที่รองรับ workload แบบเรียลไทม์ของ Solana ได้นั้นหายากในระดับโลก และเราวางแผนที่จะปรับราคาขึ้นตามความต้องการด้านฮาร์ดแวร์และเครือข่ายที่เพิ่มขึ้น การกำหนดค่าที่สเปกสูงกว่าและภูมิภาคที่มีความต้องการสูงจะขายหมดเร็วที่สุด ดังนั้นการล็อกราคาปัจจุบันไว้จึงเป็นทางเลือกที่คุ้มค่าที่สุดในระยะยาว
Q. ฉันต้องการชำระเงินด้วย crypto
การชำระด้วย crypto ใช้ได้จาก ERPC Web Dashboard เมื่อประเทศของที่อยู่สำหรับเรียกเก็บเงินที่ลงทะเบียนไว้เป็นหนึ่งในประเทศสมาชิก EU หากบัตรชำระเงินทุกใบที่ลงทะเบียนไว้ในบัญชีของคุณออกในประเทศนอก EU จะไม่สามารถชำระด้วย crypto ได้ คุณสามารถใช้ SOL, USDC หรือ EURC เพื่อซื้อ ERPC Credits ได้
ใช้ ERPC Credits เหล่านี้เพื่อเริ่มหรือใช้งานแผน ERPC ต่อ เปิด dashboard เลือกชำระเงินด้วย crypto แล้วโอนจาก wallet ของคุณ จากนั้น dashboard จะตรวจสอบ transaction และเพิ่ม credits เข้าบัญชีของคุณ
ประเทศที่รองรับ: กรีซ, โครเอเชีย, เช็ก, ไซปรัส, เดนมาร์ก, เนเธอร์แลนด์, บัลแกเรีย, เบลเยียม, โปรตุเกส, โปแลนด์, ฝรั่งเศส, ฟินแลนด์, มอลตา, เยอรมนี, โรมาเนีย, ลักเซมเบิร์ก, ลัตเวีย, ลิทัวเนีย, สเปน, สโลวะเกีย, สโลวีเนีย, สวีเดน, ออสเตรีย, อิตาลี, เอสโตเนีย, ไอร์แลนด์, ฮังการี
สำหรับประเทศที่ไม่อยู่ในรายการ โปรดชำระเงินด้วยบัตรเครดิต
Q. ทำไม ShredStream จึงไม่รวมทุก transaction?
ตามการออกแบบแล้ว Shreds จะไม่ได้รวมทุก transaction บนบล็อกเชน Solana การติดตามทุก transaction จะต้อง deploy proxy จำนวนมากทั่วโลกและรับ Shreds จาก validator ทุกราย ซึ่งไม่สามารถทำได้ในทางปฏิบัติ
โดยทั่วไป ผู้ใช้จะทำงานกับข้อมูลเพียงบางส่วนจากข้อมูลทั้งหมดที่มีอยู่ เพราะแนวทางนี้เพียงพอสำหรับการใช้งานจริงส่วนใหญ่ หากกรณีการใช้งานของคุณต้องการข้อมูลที่ครบถ้วนโดยไม่มีการสูญหายเลย Shreds อาจไม่เหมาะกับคุณ
สำหรับสถานการณ์ที่ต้องการการติดตามที่ครอบคลุมมากขึ้น Geyser gRPC ให้ความน่าเชื่อถือสูงกว่า Shreds อย่างไรก็ตาม การจะได้ข้อมูลครบ 100% บนบล็อกเชน Solana ยังคงต้อง deploy edge server จำนวนมาก ซึ่งในทางปฏิบัติอาจไม่เป็นไปได้จริง
Geyser gRPC ให้ความน่าเชื่อถือเกิน 99% ซึ่งสูงกว่า Shreds อย่างเห็นได้ชัด ข้อนี้ได้รับการยืนยันจากผู้ใช้จำนวนมาก รวมถึงตัวเราเองด้วย ส่วน Shreds โดยทั่วไปให้ความน่าเชื่อถือมากกว่า 90%
แม้ Shreds จะไม่ได้เก็บทุก transaction แต่ข้อได้เปรียบสำคัญคือสามารถดึง transaction ส่วนใหญ่ได้เร็วกว่า Geyser gRPC
เพื่อความเข้าใจที่ลึกซึ้งยิ่งขึ้น เราแนะนำให้ศึกษาโปรโตคอล Turbine และ Gulf Stream ของ Solana:
- Gulf Stream: Solana’s Mempool-less Transaction Forwarding Protocol
- Turbine — Solana’s Block Propagation Protocol Solves the Scalability Trilemma
Q. ฉันต้องการสภาพแวดล้อมที่ดีที่สุดเท่าที่จะเป็นไปได้
UDP Forwarding มีให้เลือกทั้ง Standard และ Premium ทั้งสองแบบส่ง Shreds มาถึงตัวรับของคุณจากภูมิภาคที่คุณเลือกไว้ โดยใน Standard นั้น ERPC จะส่งต่อ Shreds ออกจากโหนดในภูมิภาคนั้น Shreds จึงมาถึงคุณจาก IP ต้นทางเพียงรายการเดียว ส่วนใน Premium เครือข่าย mesh จะส่งต่อสำเนาที่มาถึงเครือข่ายก่อนของ Shred แต่ละตัว ไม่ว่าจะใช้แบบใด ให้เลือกภูมิภาคใน ERPC Web Dashboard และตั้งค่าที่อยู่ IPv4 สาธารณะและพอร์ตที่จะรับ Shreds ดิบ
กรุณาติดต่อเราผ่าน ERPC Web Dashboard เพื่อสอบถามรายละเอียดเพิ่มเติม
Q. ความหน่วงเป็นอย่างไร?
ความหน่วงแตกต่างกันไปขึ้นอยู่กับวิธีการวัดและสภาพแวดล้อมการใช้งานเฉพาะของคุณ แทนที่จะมุ่งเน้นที่ค่าตัวเลขที่แน่นอน สิ่งสำคัญคือการทำให้แน่ใจว่าความหน่วงนั้นตรงกับความต้องการในการใช้งานจริงของคุณ
เรามีเครื่องมือที่ใช้งานง่ายทั้งในภาษา TypeScript และ Rust สำหรับการวัดความหน่วง
Q. RPC (gRPC, Shreds) นี้เร็วกว่าเจ้าอื่นไหม?
เราออกแบบทุกระดับราคาโดยให้ความสำคัญกับความเร็ว และยินดีให้มีการวัดเปรียบเทียบแบบเคียงข้างกับผู้ให้บริการรายอื่นใดก็ตาม ผลลัพธ์อาจแตกต่างกันตามภูมิภาค ตามการใช้ shared endpoint หรือ dedicated endpoint ตามโปรโตคอลที่ใช้ (WebSockets, gRPC หรือ Shreds) และตามภาษาโปรแกรมที่ client ของคุณใช้
หากคุณพบว่าบริการของเราช้ากว่า โปรดแจ้งเงื่อนไขที่เจาะจงและคู่แข่งที่คุณนำมาเปรียบเทียบให้เราทราบผ่าน ERPC Web Dashboard เราจะหาสาเหตุและปรับปรุงความเร็วให้ดียิ่งขึ้น
Q. แผนไหนให้ประสิทธิภาพที่เร็วที่สุด?
โดยทั่วไปแล้ว แผนระดับสูงสุดของเราจะให้ประสิทธิภาพที่เร็วที่สุด เนื่องจากมี CPU ที่เหนือกว่า หน่วยความจำที่มากกว่า และการกำหนดค่าฮาร์ดแวร์ที่แข็งแกร่ง
เรายังมีโซลูชันที่ปรับแต่งได้หากคุณต้องการเซิร์ฟเวอร์ที่ทรงพลังยิ่งขึ้น แต่แผนมาตรฐานของเราก็ออกแบบมาเพื่อมอบอัตราส่วนราคาต่อประสิทธิภาพที่เหมาะสมที่สุด
เรามั่นใจในการมอบประสิทธิภาพระดับโลกในทุกระดับราคา หากคุณพบผู้ให้บริการที่เร็วกว่าในช่วงราคาเดียวกัน โปรดแจ้งให้เราทราบเพื่อที่เราจะได้ตรวจสอบและปรับปรุง
Q. ฉันกำลังประสบปัญหาความหน่วงสูง เพราะอะไร?
ความหน่วงจะเพิ่มขึ้นอย่างมากตามระยะห่างจาก endpoint เราขอแนะนำให้เข้าถึงจากเซิร์ฟเวอร์ที่อยู่ใกล้กับ endpoint ที่ให้มา สภาพแวดล้อมที่เร็วที่สุดมีให้บริการผ่าน เซิร์ฟเวอร์ Bare Metal และ บริการ VPS ของเรา
Q. อันไหนเร็วที่สุด: WebSockets, gRPC หรือ Shreds?
จากผลตอบรับของลูกค้า ลำดับประสิทธิภาพเป็นดังนี้:
Shreds > gRPC > WebSockets
หากประสบการณ์ของคุณแตกต่างออกไป โปรดแจ้งให้เราทราบ
Q. ความหน่วงไม่เป็นไปตามที่ฉันคาดหวัง
ประสิทธิภาพแตกต่างกันอย่างมาก ขึ้นอยู่กับภาษาโปรแกรมที่ใช้ โดยทั่วไปแล้วลำดับประสิทธิภาพเป็นดังนี้:
Rust > Go > TypeScript (JavaScript) > Python
ดูการเปรียบเทียบโดยละเอียดได้ที่:
เราขอแนะนำอย่างยิ่งให้ใช้ Rust เพื่อประสิทธิภาพสูงสุด








