ERPC

FAQ - Geyser gRPC Stream

Q. โหนดของคุณตั้งอยู่ในภูมิภาคใดบ้าง?

ปัจจุบันเราให้บริการโหนดในภูมิภาคต่อไปนี้:
  • Frankfurt (FRA)
  • Amsterdam (AMS)
  • London (LON)
  • New York (NY)
  • Tokyo (TY)
  • Singapore (SGP)
  • Sydney (SYD)
ERPC วัดความหน่วงของเครือข่ายจริงโดยอ้างอิงจากเส้นทาง routing จริง และเลือกภูมิภาคที่มีความหน่วงต่ำที่สุดโดยอัตโนมัติ แทนที่จะอาศัยระยะทางในแนวเส้นตรง วิธีนี้ไม่เพียงช่วยลดความหน่วงให้กับผู้ใช้แต่ละราย แต่ยังเพิ่มประสิทธิภาพโดยรวมของเครือข่าย และเสริมความแข็งแกร่งของ ERPC ในระดับโลกต่อการโจมตีที่อาจเกิดขึ้นด้วย
หากสภาพแวดล้อมของคุณไม่ได้เลือกภูมิภาคที่เหมาะสมที่สุดโดยอัตโนมัติ โปรดติดต่อเราผ่าน ERPC Web Dashboard
ERPC Web Dashboard: https://dashboard.erpc.global/th

Q. ค่าความหน่วงแสดงเป็น 9999ms และระบบเลือกภูมิภาคที่ไม่เหมาะสม ควรทำอย่างไร?

สำหรับการเลือกภูมิภาคของ gRPC นั้น ERPC จะส่งโพรบวัดเวลาแฝง ICMP ไปยัง IP ที่ลงทะเบียนของคุณจากโฮสต์พร็อกซีที่แสดงด้านล่าง อนุญาตคำขอ ICMP echo ขาเข้าจาก IP ต้นทางที่แสดงไว้ทั้งหมด หากถูกไฟร์วอลล์ (ufw, ไฟร์วอลล์ระบบคลาวด์, กลุ่มความปลอดภัย เป็นต้น) บล็อก ค่าที่วัดได้อาจเป็น 9999ms และอาจมีการเลือกภูมิภาคที่ไม่เหมาะสม IP หลายรายการในภูมิภาคเดียวกันมาจากโฮสต์โพรบคนละเครื่อง และจำเป็นต้องอนุญาตทั้งหมด
ภูมิภาคIP ต้นทาง ICMP
🇳🇱 Amsterdam82.21.43.34, 151.244.92.36
🇺🇸 New York151.243.244.5
🇩🇪 Frankfurt151.241.178.20, 151.241.178.34, 151.241.178.21
🇬🇧 London151.241.65.4
🇯🇵 Tokyo143.20.238.66
🇸🇬 Singapore151.245.186.2
🛰️ Far Point143.20.238.73

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 ฉันสามารถใช้ gRPC ได้ไหม? มีตัวอย่างให้ดูไหม?

ได้ คุณสามารถทดสอบและเริ่มพัฒนาด้วย gRPC ได้อย่างรวดเร็วโดยใช้ SLV
สำหรับ endpoint แบบใช้ร่วมกันที่คุณสามารถทดสอบได้โดยไม่ต้องใช้ token ให้รันคำสั่ง:
bash
slv check grpc --endpoint <YOUR_ENDPOINT> --token none
ดูรายละเอียดได้ที่ คู่มือเริ่มต้นใช้งาน gRPC ของเรา

Q. ฉันสามารถลงทะเบียน IP address สองรายการได้ไหม?

คุณสามารถใช้หนึ่ง endpoint ต่อหนึ่ง subscription หากคุณต้องการใช้ IP address สองรายการ คุณจะต้องสมัครสอง subscription แยกกัน

Q. มีข้อจำกัดของ filter หรือไม่?

Shared Geyser gRPC มีการคุ้มครองการใช้งานอย่างเป็นธรรม เพื่อไม่ให้ stream หนึ่งใช้ทรัพยากรที่ลูกค้า ERPC รายอื่นต้องใช้ ภายใต้กฎ Shared ปัจจุบัน blocks map ที่ไม่ว่างทุกแบบจะถูกปฏิเสธ รวมถึงคำขอ block ที่จำกัดขอบเขตแล้วด้วย แต่ละ account filter ต้องมี account, owner หรือ cuckoo filter ที่รองรับ ส่วน memcmp หรือ dataSize เพียงอย่างเดียวไม่เพียงพอ
นำ shape ที่ถูกปฏิเสธออก และ subscribe เฉพาะข้อมูลที่แอปพลิเคชันของคุณต้องใช้ ทั้งนี้ transaction subscription หรือ block metadata อาจตอบโจทย์ได้โดยไม่ต้องรับ full block Dedicated Geyser gRPC เหมาะเมื่อ workload ที่จำเป็นจริงเกิน shape หรือ resource allowance ของ Shared แต่ Dedicated ไม่ได้ทำให้ parameter ที่ไม่ถูกต้องใช้งานได้ และไม่ได้แก้ client ที่ช้า

Q. ควรเก็บ gRPC error อย่างไรก่อนเชื่อมต่อใหม่?

เก็บ error แรกไว้ก่อนที่ reconnect loop จะเขียนทับ บันทึก gRPC status และ message จาก initial metadata และ trailer พร้อม x-erpc-error-code, x-erpc-error-reason และ x-erpc-doc-url หาก ERPC ส่ง pause ให้บันทึก x-erpc-retry-after-seconds และ x-erpc-retry-at (Unix seconds) ด้วย
Error อาจแสดงเป็น ERPC [STREAM_GUARD_SLOW_READER]: ... ให้วาง error ที่แสดงหรือ code ของมันลงใน FAQ search สำหรับคำอธิบายมาตรฐาน ให้ใช้ ERPC gRPC FAQ อย่าคิดว่าจะได้รับ trailer เสมอเมื่อการเชื่อมต่อปิดเร็ว
ค้นหาตาม symptom ได้เช่นกัน: slow receiver, disconnected, bandwidth, delivery lag, backlog, pause, retry, invalid argument, resource exhausted, permission denied, IP registration, too many streams, full blocks หรือ all accounts

Q. gRPC error ใดบ้างที่ทำให้ connection ของฉันถูก pause และ client ของฉันควรหยุด reconnect เมื่อไร?

Pause คือช่วงเวลาที่กำหนดไว้ซึ่ง ERPC ตั้งขึ้นหลังจาก error บางประเภท Client ต้องไม่ reconnect ระหว่างที่ pause ทำงานอยู่
สิ่งที่ถูกนับ Error ต่อไปนี้ถูกนับ และใช้ลำดับขั้นชุดเดียวกัน:
  • Subscribe request ทุกรายการที่ ERPC ปฏิเสธด้วย ERPC_GRPC_INVALID_ARGUMENT, STREAM_GUARD_SHAPE_BLOCKS หรือ STREAM_GUARD_SHAPE_ACCOUNTS_ALL รวมถึงรายการแรกด้วย Error ที่ถูกนับรายการแรกคือ warning ซึ่งไม่เริ่ม pause
  • STREAM_GUARD_SLOW_READER อย่างไรก็ตาม หาก delivery lag เกิดขึ้นที่ฝั่งของ ERPC ทาง ERPC จะปิด stream โดยไม่นับครั้งนั้น และ error ที่ได้รับจะไม่มี retry deadline
สิ่งที่ไม่ถูกนับ: การ reconnect เอง, STREAM_ADMISSION_* ทั้งสี่ code (STREAM_ADMISSION_LIMIT_REACHED, STREAM_ADMISSION_IP_NOT_ADMITTED, STREAM_ADMISSION_SOURCE_UNAVAILABLE และ STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE) และ error ที่ถูกนับใด ๆ ที่เกิดขึ้นระหว่างที่ pause ทำงานอยู่ Error ที่ถูกนับซึ่งเกิดระหว่าง pause จะไม่ทำให้ pause ยาวขึ้นและไม่เลื่อนไปขั้นถัดไป
ลำดับขั้น Error ที่ถูกนับแต่ละรายการจะเลื่อนไปหนึ่งขั้นตามลำดับนี้ โดยเริ่มจาก warning:
  • Warning: ไม่มี pause
  • Pause 60 วินาที
  • Pause 300 วินาที
  • Pause 1800 วินาที
  • Pause 86400 วินาที (24 ชั่วโมง) นี่คือขั้นสุดท้าย: ที่ขั้นนี้ error ที่ถูกนับแต่ละรายการจะเริ่ม pause 86400 วินาที อีกช่วงหนึ่ง
ที่ขั้น warning จะเลื่อนไปที่ pause 60 วินาที ก็ต่อเมื่อ error ที่ถูกนับรายการถัดไปเกิดขึ้นภายใน 1 ชั่วโมงหลัง warning เท่านั้น Error ที่ถูกนับซึ่งเกิดขึ้นหลัง warning มากกว่า 1 ชั่วโมงจะเป็น warning ใหม่ที่ไม่มี pause และ window 1 ชั่วโมงจะเริ่มจาก warning ใหม่นั้น
Error ที่ถูกนับซึ่งเกิดขึ้นน้อยกว่า 60 วินาที หลัง error ล่าสุดที่ถูกนับ จะนับเป็นส่วนหนึ่งของ error นั้นและไม่เลื่อนขั้นใด ๆ
ขั้นจะกลับไปที่ warning เมื่อไร เมื่อลำดับขั้นเริ่ม pause แล้ว ขั้นจะกลับไปที่ warning ก็ต่อเมื่อผ่านไป 24 ชั่วโมงโดยไม่มี error ที่ถูกนับและไม่มี pause โดยวัดจากจุดสิ้นสุดของ pause ล่าสุด; error ที่ถูกนับรายการถัดไปหลังจากนั้นจะเป็น warning ที่ไม่มี pause ก่อนถึงตอนนั้น error ที่ถูกนับรายการถัดไปจะเริ่มขั้นถัดไปทันทีโดยไม่มี warning
Pause egress STREAM_GUARD_EGRESS_BUDGET เริ่ม pause คงที่ของตัวเองเป็นเวลา 600 วินาที Code นี้ไม่เลื่อนขั้น
เวลาสิ้นสุดอยู่ที่ไหน
  • Error ที่เริ่ม pause จะมี Retry after N seconds. และ headers x-erpc-retry-after-seconds และ x-erpc-retry-at (Unix seconds) Warning ไม่มีเวลา retry
  • เมื่อ request ที่ถูกปฏิเสธซึ่งถูกนับเป็นตัวที่เริ่ม pause คำตอบของ request นั้นจะเป็น STREAM_GUARD_SHAPE_REJECT_PENALTY พร้อม ResourceExhausted (8) แทน code ของตัวเอง
  • ระหว่าง pause จาก slow-reader หรือ egress การ reconnect จะได้รับ STREAM_GUARD_PENALTY_ACTIVE พร้อมเวลาที่เหลือ
  • ระหว่าง pause ที่เริ่มจาก request ที่ถูกปฏิเสธ connection ใหม่จะถูกปิดทันทีโดยไม่มี gRPC status และไม่มี ERPC code ส่วน request บน connection ที่ยังเปิดอยู่อาจได้รับคำตอบเป็น STREAM_GUARD_SHAPE_REJECT_PENALTY พร้อมเวลาที่เหลืออีกครั้งก่อนที่ connection นั้นจะถูกปิด Client อาจไม่เห็นเวลาสิ้นสุดอีกเลย จึงต้องบันทึก x-erpc-retry-at จาก error แรกที่มีค่านี้
Codeสถานะ gRPCเริ่ม pause หรือเลื่อนขั้นของ pause หรือไม่?สิ่งที่ client ต้องทำ
ERPC_GRPC_INVALID_ARGUMENTInvalidArgument (3)ใช่ เมื่อปฏิเสธ Subscribe request ในกรณีนั้นเป็น error ที่ถูกนับตามลำดับขั้นด้านบนหยุด loop และอย่าส่ง request เดิมซ้ำ Entry ของตัวเองด้านล่างระบุสิ่งที่ต้องตรวจสอบ
STREAM_GUARD_SHAPE_BLOCKSPermissionDenied (7)ใช่ เป็น error ที่ถูกนับตามลำดับขั้นด้านบนหยุด loop และอย่าส่ง request เดิมซ้ำ Entry ของตัวเองด้านล่างระบุสิ่งที่ต้องตรวจสอบ
STREAM_GUARD_SHAPE_ACCOUNTS_ALLPermissionDenied (7)ใช่ เป็น error ที่ถูกนับตามลำดับขั้นด้านบนหยุด loop และอย่าส่ง request เดิมซ้ำ Entry ของตัวเองด้านล่างระบุสิ่งที่ต้องตรวจสอบ
STREAM_GUARD_SLOW_READERResourceExhausted (8)ใช่ เป็น error ที่ถูกนับตามลำดับขั้นด้านบน อย่างไรก็ตาม หาก delivery lag เกิดขึ้นที่ฝั่งของ ERPC ทาง ERPC จะปิด stream โดยไม่นับครั้งนั้น และ error ที่ได้รับจะไม่มี retry deadlineหยุด loop Entry ของตัวเองด้านล่างระบุสิ่งที่ต้องตรวจสอบ หาก error นี้เริ่ม pause อย่า reconnect ก่อนเวลาใน x-erpc-retry-at
STREAM_GUARD_EGRESS_BUDGETResourceExhausted (8)ใช่ code นี้เริ่ม pause คงที่ 600 วินาที นอกลำดับขั้นด้านบนอย่า reconnect ก่อนเวลาใน x-erpc-retry-at Entry ของตัวเองด้านล่างระบุสิ่งที่ต้องตรวจสอบ
STREAM_GUARD_SHAPE_REJECT_PENALTYResourceExhausted (8)ใช่ เป็น request ที่ถูกปฏิเสธซึ่งถูกนับและเป็นตัวที่เริ่ม pause และ code นี้อาจถูกส่งกลับอีกครั้งพร้อมเวลาที่เหลือบน connection ที่ยังเปิดอยู่อย่า reconnect ก่อนเวลาใน x-erpc-retry-at แก้ request ที่ถูกปฏิเสธ และอย่าส่งซ้ำโดยไม่แก้ไข
STREAM_GUARD_PENALTY_ACTIVEResourceExhausted (8)ไม่ใช่ code นี้รายงาน pause จาก slow-reader หรือ egress ที่ทำงานอยู่แล้วอย่า reconnect ก่อนเวลาใน x-erpc-retry-at
STREAM_ADMISSION_LIMIT_REACHEDResourceExhausted (8)ไม่ใช่ ไม่มี pause แบบกำหนดเวลาปิด stream ที่ไม่ใช้ แล้ว retry
STREAM_ADMISSION_IP_NOT_ADMITTEDPermissionDenied (7)ไม่ใช่ ไม่มี pause แบบกำหนดเวลาEntry ของตัวเองด้านล่างระบุสิ่งที่ต้องตรวจสอบ
STREAM_ADMISSION_SOURCE_UNAVAILABLEUnavailable (14)ไม่ใช่ ไม่มี pause แบบกำหนดเวลาให้ back off ตามปกติ แล้วลองใหม่หลังหน่วงเวลา
STREAM_ADMISSION_SNAPSHOT_UNAVAILABLEUnavailable (14)ไม่ใช่ ไม่มี pause แบบกำหนดเวลาให้ back off ตามปกติ แล้วลองใหม่หลังหน่วงเวลา
สิ่งที่ client ต้องทำ เมื่อเกิด error ที่ถูกนับ ให้หยุด loop อย่าส่ง request เดิมซ้ำ และแก้ไข request นั้น ระหว่าง pause อย่า reconnect ก่อนเวลาใน x-erpc-retry-at Subscribe request ที่ถูกปฏิเสธถูกนับตามกฎด้านบน ส่วนการ reconnect ไม่ถูกนับ

Q. STREAM_GUARD_SLOW_READER พร้อม ResourceExhausted (8) หมายความว่าอะไรเมื่อ slow receiver ถูกตัดการเชื่อมต่อ?

ERPC พบว่า stream นี้มี write progress ไม่เพียงพอหรือมี delivery lag แต่ delivery lag เพียงอย่างเดียวไม่สามารถบอกสาเหตุได้ ตรวจสอบ network loss, effective bandwidth, host hardware และว่า application consumer ตามทันหรือไม่ ลดข้อมูลที่ subscribe และย้าย processing ออกจาก receive loop ไปยัง bounded queue ทั้งนี้ bounded queue ช่วยควบคุมการใช้ memory แต่ไม่อาจแก้ consumer ที่ช้าอย่างต่อเนื่องได้ หาก ERPC ให้ retry deadline ให้รอก่อน reconnect คำถาม “ทำไม gRPC stream ของฉันถึงมีความเร็วค้างอยู่ที่ระดับเดิมและตามหลังไปเรื่อย ๆ?” ด้านล่างอธิบายหน้าต่างการรับข้อมูลและวิธีขยายหน้าต่างในไลบรารีของ client

Q. ทำไม gRPC stream ของฉันถึงมีความเร็วค้างอยู่ที่ระดับเดิมและตามหลังไปเรื่อย ๆ?

หน้าต่างการรับข้อมูลที่เล็กใน client ของคุณ หรือในสิ่งที่อยู่ระหว่าง client กับ ERPC อาจทำให้ stream ถูกตัดด้วย STREAM_GUARD_SLOW_READER และเกิด pause ตามมาหลังจากนั้น คำตอบนี้อธิบายว่าหน้าต่างการรับข้อมูลคืออะไร จะรู้ได้อย่างไรว่ามันจำกัด stream ของคุณอยู่หรือไม่ และจะขยายหน้าต่างในแต่ละไลบรารีได้อย่างไร คำถาม “gRPC error ใดบ้างที่ทำให้ connection ของฉันถูก pause และ client ของฉันควรหยุด reconnect เมื่อไร?” ด้านบนอธิบายลำดับขั้นและระยะเวลาของแต่ละขั้น
หน้าต่างการรับข้อมูลคืออะไร ใน HTTP/2 ฝั่งผู้รับจะแจ้งฝั่งผู้ส่งว่าส่งข้อมูลได้มากเท่าใดก่อนที่ผู้รับจะยืนยัน ปริมาณนี้คือหน้าต่างการรับข้อมูล (HTTP/2 flow control window) การไป-กลับหนึ่งรอบส่งข้อมูลได้ไม่เกินหนึ่งหน้าต่าง ความเร็วจึงสูงสุดอยู่ที่ประมาณขนาดหน้าต่างหารด้วยเวลาไป-กลับ (เวลาที่ใช้เดินทางไปถึง endpoint และกลับมา)
ขีดจำกัดอื่น ๆ หน้าต่างมีสองแบบ คือแบบต่อ stream และแบบต่อ connection (ทุก stream บน connection เดียวกันใช้ร่วมกัน) และหน้าต่างที่เล็กกว่าจะเป็นตัวกำหนดขีดจำกัด ตามข้อกำหนดของ HTTP/2 หน้าต่างทั้งสองเริ่มต้นที่ 65,535 ไบต์ TCP receive buffer (memory สำหรับข้อมูลขาเข้า) ก็จำกัดความเร็วในลักษณะเดียวกัน Proxy, load balancer, gateway, VPN หรือ sidecar ที่อยู่ระหว่างทางก็มีหน้าต่างและ buffer ของตัวเอง หากหน้าต่างหรือ buffer ที่จุดนั้นเล็ก stream ก็จะถูกจำกัดความเร็ว แม้หน้าต่างใน client ของคุณเองจะใหญ่ก็ตาม
ลักษณะที่เห็น Stream หนึ่งจะนิ่งอยู่ที่ความเร็วเกือบเท่าเดิมไม่ว่า chain จะคึกคักแค่ไหน และ delivery lag ของ stream นั้นจะเพิ่มขึ้นอย่างสม่ำเสมอ ERPC วัดจากจุดที่มีเวลาไป-กลับประมาณ 6 ms ไปยัง shared endpoint ใน Frankfurt โดยเปลี่ยนเฉพาะหน้าต่างระหว่างการวัดแต่ละรอบ:
  • หน้าต่างของ stream 16 KiB: คงที่อยู่ที่ประมาณ 2.7 MB/s (16 KiB หารด้วย 6 ms) delivery lag เพิ่มขึ้นประมาณ 0.6 วินาทีต่อวินาที และเมื่อผ่านไป 45 วินาทีก็ถึง 26 วินาที
  • ทั้งสองหน้าต่าง 16 MiB: delivery lag สูงสุดคือ 14 ms
หาก delivery lag เกิดขึ้นที่ฝั่งของ ERPC ทาง ERPC จะปิด stream โดยไม่นับครั้งนั้น และ error ที่ได้รับจะไม่มี retry deadline
ตรวจสอบ
  1. เปรียบเทียบความเร็วและ delivery lag ของ stream กับรูปแบบด้านบน
  2. วัดเวลาไป-กลับ แล้วนำความเร็วของ stream คูณกับเวลาไป-กลับเพื่อประมาณขนาดหน้าต่าง (2.7 MB/s คูณ 6 ms ได้ประมาณ 16 KB)
  3. ตรวจสอบหน้าต่างทั้งสองของ client ว่ามีค่าใดตั้งไว้เล็กหรือไม่ หรือมีการปิดการขยายอัตโนมัติ (ไลบรารีขยายหน้าต่างเอง) ไว้หรือไม่
  4. ตรวจสอบ TCP receive buffer บน Linux ให้รัน sysctl net.ipv4.tcp_rmem net.core.rmem_max และดูว่าแอปพลิเคชันของคุณตั้งค่า SO_RCVBUF หรือไม่ การตั้งค่านี้จะปิดการปรับขนาดอัตโนมัติ
  5. ตรวจสอบหน้าต่างและ buffer ของทุกสิ่งที่อยู่ระหว่างทาง
  6. หากความเร็วไม่มีเพดานและมีเพียง lag ที่เพิ่มขึ้น แสดงว่า processing หลังรับข้อมูลช้า คำถาม “STREAM_GUARD_SLOW_READER พร้อม ResourceExhausted (8) หมายความว่าอะไรเมื่อ slow receiver ถูกตัดการเชื่อมต่อ?” ด้านบนอธิบายการให้ receive loop ทำหน้าที่อ่านอย่างเดียว และย้ายงานหนักไปยัง bounded queue
การตั้งค่าตามไลบรารี ตัวอย่างตั้งหน้าต่างทั้งสองเป็น 16 MiB เหมือนกับการวัดของ ERPC สำหรับไลบรารีที่ไม่ได้อยู่ในรายการ ให้หาการตั้งค่า initial window ของ HTTP/2
Rust, yellowstone-grpc-client หากไม่ได้ตั้งค่าหน้าต่าง GeyserGrpcClient::build_from_shared จะใช้ 2 MiB ต่อ stream และ 5 MiB ต่อ connection ที่เวลาไป-กลับ 6 ms ค่าเริ่มต้นเหล่านี้รองรับได้มากกว่า 300 MB/s จึงไม่จำกัด stream หากต้องการตั้งหน้าต่างเอง ให้ใช้ builder method ทั้งสองตัว และปิด http2_adaptive_window ไว้ หากเปิดไว้ หน้าต่างจะเริ่มที่ 65,535 ไบต์และขยายเองได้ถึง 16 MiB โดยไม่สนใจค่าที่คุณตั้ง
rust
// ตั้งหน้าต่างทั้งสองตายตัวที่ 16 MiB และต้องปิด http2_adaptive_window ไว้
let client = GeyserGrpcClient::build_from_shared(endpoint)?
    .tls_config(ClientTlsConfig::new().with_native_roots())?
    .initial_stream_window_size(16 * 1024 * 1024)
    .initial_connection_window_size(16 * 1024 * 1024)
    .connect()
    .await?;
TypeScript, @triton-one/yellowstone-grpc 5.0.1 ขึ้นไป ค่าเริ่มต้น: 4 MiB ต่อ stream, 8 MiB ต่อ connection และเปิดการขยายอัตโนมัติไว้ หน้าต่างเริ่มที่ 64 KiB และขยายได้ถึง 16 MiB ค่าเริ่มต้นจึงไม่ค่อยจำกัด stream หากต้องการกำหนดขนาดตายตัว ให้ส่ง argument ตัวที่สามพร้อม grpcHttp2AdaptiveWindow: false
typescript
// ปิด adaptive window ไว้ จึงใช้ขนาดตายตัวเหล่านี้
const client = new Client(endpoint, undefined, {
  grpcInitialStreamWindowSize: 16 * 1024 * 1024,
  grpcInitialConnectionWindowSize: 16 * 1024 * 1024,
  grpcHttp2AdaptiveWindow: false,
})
TypeScript, @triton-one/yellowstone-grpc 5.0.0 หรือต่ำกว่า เวอร์ชันเหล่านี้ใช้ @grpc/grpc-js ซึ่งมีหน้าต่างค่าเริ่มต้น 65,535 ไบต์: ประมาณ 11 MB/s ที่ 6 ms และประมาณ 0.66 MB/s ที่ 100 ms ตั้งแต่เวอร์ชัน 1.14 @grpc/grpc-js นำ 'grpc-node.flow_control_window' ไปใช้กับหน้าต่างทั้งสอง ส่วนเวอร์ชัน 1.13 ใช้ค่านี้กับหน้าต่าง stream เท่านั้น หน้าต่าง connection จึงยังอยู่ที่ 65,535 ไบต์ (ประมาณ 11 MB/s ที่ 6 ms) หาก @grpc/grpc-js เก่ากว่าเวอร์ชัน 1.14 การอัปเกรดเป็น @triton-one/yellowstone-grpc 5.0.1 ขึ้นไปจะเป็นทางที่เร็วกว่า
typescript
// ต้องใช้ @grpc/grpc-js 1.14 ขึ้นไปจึงจะขยายหน้าต่างทั้งสองได้
const client = new Client(endpoint, undefined, {
  'grpc-node.flow_control_window': 16 * 1024 * 1024,
})
Go, google.golang.org/grpc โดยค่าเริ่มต้น ไลบรารีจะขยายหน้าต่างเองได้ถึง 16 MiB ส่วน grpc.WithInitialWindowSize และ grpc.WithInitialConnWindowSize จะกำหนดหน้าต่างตายตัวและปิดการขยายอัตโนมัติ ค่าที่ต่ำกว่า 64 KiB จะถูกละเว้น ให้ตั้งทั้งสองค่า: หากตั้งเพียงค่าเดียว อีกค่าจะยังคงอยู่ที่ 64 KiB
go
// ตั้งทั้งสองค่า การตั้งค่านี้ยังปิดการขยายหน้าต่างอัตโนมัติด้วย
conn, err := grpc.NewClient(target,
	grpc.WithTransportCredentials(creds),
	grpc.WithInitialWindowSize(16<<20),
	grpc.WithInitialConnWindowSize(16<<20),
)
Python, grpcio grpc.http2.bdp_probe เปิดอยู่โดยค่าเริ่มต้น หน้าต่างจึงขยายเอง หากโค้ดของคุณส่ง ("grpc.http2.bdp_probe", 0) ให้ลบออก grpc.http2.lookahead_bytes กำหนดปริมาณการอ่านล่วงหน้าต่อ stream (ค่าเริ่มต้น 64 KB) ค่าที่มากขึ้นอาจช่วยได้เมื่อเวลาไป-กลับนาน
python
# หาก options มี ("grpc.http2.bdp_probe", 0) ให้ลบออก
channel = grpc.secure_channel(target, creds, options=[
    ("grpc.http2.lookahead_bytes", 16 * 1024 * 1024),
])
รับข้อมูลให้ใกล้ขึ้น เวลาไป-กลับที่สั้นลงทำให้หน้าต่างขนาดเดิมส่งข้อมูลได้มากขึ้น บริการ VPS และ เซิร์ฟเวอร์ Bare Metal ของ ERPC ช่วยให้วาง client ไว้ใกล้ endpoint ได้
แบ่งอย่างระมัดระวัง Standard รองรับ 10 stream และ Premium รองรับ 50 stream ต่อ source IP ที่ลงทะเบียนไว้ แต่ละ stream ได้หน้าต่าง stream ของตัวเอง แต่ stream บน connection เดียวกันใช้หน้าต่าง connection ร่วมกันหนึ่งหน้าต่าง หากหน้าต่าง connection เล็ก ความเร็วก็ยังถูกจำกัดอยู่ เมื่อจะเปลี่ยน stream ให้ปิด stream เก่าก่อน: stream ที่เปิดอยู่จะถูกนับรวมในขีดจำกัด และหากเกินจะได้รับ STREAM_ADMISSION_LIMIT_REACHED (มีคำถามเฉพาะอยู่ด้านล่าง) การแบ่ง stream ไม่ได้ทำให้ processing ที่ช้าเร็วขึ้น

Q. STREAM_GUARD_EGRESS_BUDGET พร้อม ResourceExhausted (8) หมายความว่าอะไร?

Traffic รวมจาก IP นี้เกิน Shared allowance ดังนั้น stream ที่เกี่ยวข้องอาจถูกปิดพร้อมกัน ลดปริมาณข้อมูลและ parallel stream ที่ไม่จำเป็น แล้วรอจนถึง deadline ที่ส่งกลับมา Pause egress นี้คงที่ที่ 600 วินาที และไม่เลื่อนขั้นของ penalty ladder แต่ pause ที่ยาวกว่าซึ่งมีผลอยู่แล้วอาจยังคงมีผลต่อไป

Q. STREAM_GUARD_PENALTY_ACTIVE พร้อม ResourceExhausted (8) หมายความว่าอะไร?

Pause จาก slow-reader หรือ egress ก่อนหน้านี้ยังทำงานอยู่ และ response นี้มีเวลาที่เหลือ เก็บ ERPC error แรก แก้สาเหตุ และอย่า reconnect ก่อน x-erpc-retry-at อย่า reconnect เร็วเพื่อทดสอบ ความพยายาม reconnect ไม่ถูกนับ คำถาม “gRPC error ใดบ้างที่ทำให้ connection ของฉันถูก pause และ client ของฉันควรหยุด reconnect เมื่อไร?” ด้านบนอธิบายลำดับขั้นและระยะเวลาของแต่ละขั้น

Q. STREAM_GUARD_SHAPE_BLOCKS พร้อม PermissionDenied (7) หมายความว่าอะไร?

กฎ Shared ปัจจุบันปฏิเสธ blocks map ที่ไม่ว่างทุกแบบ แม้ request จะแคบ ให้นำ blocks map ออก ใช้ transactions และ/หรือ block metadata เมื่อเพียงพอ แต่ทั้งสองอย่างไม่เทียบเท่า full block หากต้องการ full blocks ให้ใช้ Dedicated Geyser gRPC ทั้งนี้ไม่ได้หมายความว่ามี Shared plan แบบ selective-block ให้ใช้

Q. STREAM_GUARD_SHAPE_ACCOUNTS_ALL พร้อม PermissionDenied (7) หมายความว่าอะไร?

Account-filter entry ต้องเลือกข้อมูลด้วย account, owner หรือ cuckoo filter ที่รองรับ ส่วน memcmp และ dataSize เพียงอย่างเดียวไม่เพียงพอ จำกัด account request ให้เป็นหนึ่งใน shape ที่รองรับ หรือใช้ Dedicated Geyser gRPC เมื่อต้องการ full account stream

Q. STREAM_GUARD_SHAPE_REJECT_PENALTY พร้อม ResourceExhausted (8) หมายความว่าอะไร?

Code นี้ถูกส่งกลับแทน ERPC_GRPC_INVALID_ARGUMENT, STREAM_GUARD_SHAPE_BLOCKS หรือ STREAM_GUARD_SHAPE_ACCOUNTS_ALL เมื่อ request ที่ถูกปฏิเสธซึ่งถูกนับนั้นเป็นตัวที่เริ่ม pause; คำถาม “gRPC error ใดบ้างที่ทำให้ connection ของฉันถูก pause และ client ของฉันควรหยุด reconnect เมื่อไร?” ด้านบนระบุว่ากรณีนี้เกิดขึ้นเมื่อไร Code นี้มี Retry after N seconds., x-erpc-retry-after-seconds และ x-erpc-retry-at ระหว่าง pause นี้ connection ใหม่จะถูกปิดทันทีโดยไม่มี gRPC status และไม่มี ERPC code ดังนั้น client อาจไม่เห็นเวลาสิ้นสุดอีกเลย บันทึก x-erpc-retry-at จาก error แรกที่มีค่านี้ Subscribe request ที่ถูกปฏิเสธถูกนับตามกฎด้านบน ส่วนการ reconnect ไม่ถูกนับ แก้ request และอย่าส่งซ้ำโดยไม่แก้ไข Connection drop เร็วอาจดูเหมือน transport error จึงต้องเก็บ ERPC error แรกก่อน reconnect loop จะซ่อนมัน

Q. STREAM_ADMISSION_LIMIT_REACHED พร้อม ResourceExhausted (8) หมายความว่าอะไร?

Admission allowance เต็มอยู่ในขณะนี้ ปิด stream ที่ไม่ใช้หรือซ้ำ ตรวจสอบ allowance ของ connection และ retry เมื่อมี capacity พร้อม Response นี้เพียงอย่างเดียวไม่ได้หมายความว่า timed penalty ทำงานอยู่

Q. STREAM_ADMISSION_IP_NOT_ADMITTED พร้อม PermissionDenied (7) หมายความว่าอะไร?

ERPC ไม่สามารถ admit connection ได้ รวมถึงกรณีหลังจาก grace period ของการลงทะเบียน IP หมดอายุ เปรียบเทียบ outbound IP จริงกับ IP ที่ลงทะเบียนไว้ และยืนยัน access state ปัจจุบัน รอให้การเปลี่ยนแปลงการลงทะเบียนมีผล โดยอย่าคาดว่าจะใช้เวลาตายตัว และติดต่อ support หากยังเกิดอยู่

Q. STREAM_ADMISSION_SOURCE_UNAVAILABLE พร้อม Unavailable (14) หมายความว่าอะไร?

ERPC ระบุ source ของ connection นี้ไม่ได้ในขณะนั้น ให้ back off แล้วลองใหม่หลังหน่วงเวลา หากยังเกิดอยู่ให้ติดต่อ support พร้อม error แรกและ metadata ทั้งนี้ response นี้ไม่ได้ยืนยันว่า network หรือ server ของลูกค้ามี fault

Q. STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE พร้อม Unavailable (14) หมายความว่าอะไร?

ERPC ไม่สามารถตรวจสอบ access ได้ในขณะนั้น ให้ back off แล้วลองใหม่หลังหน่วงเวลา และติดต่อ support หากยังเกิดอยู่ การ re-register ซ้ำ ๆ การขยาย filter หรือการซื้อ Dedicated Geyser gRPC ไม่แก้ availability response นี้

Q. ERPC_GRPC_INVALID_ARGUMENT พร้อม InvalidArgument (3) หมายความว่าอะไร?

Request มี parameter, option, field type, key หรือ filter combination ที่ไม่ถูกต้อง แก้ request ก่อน retry และอย่าส่ง request เดิมซ้ำ Subscribe request ทุกรายการที่ถูกปฏิเสธด้วย code นี้เป็น error ที่ถูกนับตามกฎ pause ในคำถาม “gRPC error ใดบ้างที่ทำให้ connection ของฉันถูก pause และ client ของฉันควรหยุด reconnect เมื่อไร?” ด้านบน และกฎเดียวกันนี้ใช้กับ STREAM_GUARD_SHAPE_BLOCKS, STREAM_GUARD_SHAPE_ACCOUNTS_ALL และ STREAM_GUARD_SLOW_READER ด้วย เมื่อ request ดังกล่าวเริ่ม pause คำตอบของ request นั้นจะเป็น STREAM_GUARD_SHAPE_REJECT_PENALTY พร้อม ResourceExhausted (8) Dedicated Geyser gRPC ไม่ทำให้ parameter ที่ไม่ถูกต้องถูกต้องขึ้น
ข้อความ error จะต่อท้ายโค้ดด้วย (reason: <token>) และ token เดียวกันจะถูกส่งกลับใน response header x-erpc-error-reason ให้ค้นหา token ด้านล่างเพื่อดูว่าต้องแก้อะไร หากมีขีดจำกัดที่ใช้อยู่ ข้อความ error จะระบุไว้
Reasonความหมายสิ่งที่ต้องแก้
too_many_filtersrequest มี filter ที่ตั้งชื่อหรือ data slice มากกว่าที่ request หนึ่งรับได้ใช้ filter ที่ตั้งชื่อ (หรือ data slice) ประเภทนี้ให้น้อยลงต่อ request
empty_filterfilter ไม่มี address เลย และ filter ที่ว่างหมายถึงทุกอย่างใส่ address อย่างน้อยหนึ่งรายการในทุก filter (account: account หรือ owner; transaction: รายการ account) Shared gRPC ไม่รองรับ filter ที่ว่าง
too_many_addressesช่อง filter หนึ่งมี address มากเกินไปใช้ address ในช่อง filter หนึ่งให้น้อยลง แบ่งไปไว้หลาย filter หรือจำกัดรายการให้แคบลง
address_not_allowedfilter ระบุ address ที่ Shared gRPC ไม่อนุญาตเอา address ที่มีปริมาณสูงนั้นออกจาก filter
filter_name_too_longชื่อ filter ยาวเกินไปใช้ชื่อ filter ที่สั้นลง (key ของ map)
invalid_commitmentระดับ commitment ไม่ถูกต้องใช้ processed, confirmed หรือ finalized
invalid_addressfilter มี address ที่ไม่ถูกต้องทำให้ทุก address เป็น address Solana แบบ base58 ที่ถูกต้อง (ห้ามมี string ว่าง ช่องว่าง หรือความยาวผิด)
invalid_signatureค่า signature ของ transaction ไม่ถูกต้องใช้ signature ของ transaction แบบ base58 ที่ถูกต้อง
invalid_account_data_filterfilter ข้อมูลของ account ไม่ถูกต้องแก้ filter memcmp, datasize และข้อมูล token account และให้จำนวนอยู่ในขีดจำกัดที่ระบุในข้อความ
invalid_data_slicedata slice ไม่ถูกต้องเรียง data slice ตาม offset และอย่าให้ซ้อนทับกัน
blocks_include_not_allowedตัวเลือกของ subscription blocks ใช้ไม่ได้บน Shared gRPCไม่ต้องระบุ blocks และใช้ subscription ของ transaction หรือ blocks_meta แทน
invalid_token_accounts_modeโหมด token accounts ไม่ถูกต้องใช้ ALL (0) หรือ BALANCE_CHANGED (1)
invalid_argumentไม่มีเหตุผลข้างต้นข้อใดตรงตรวจสอบ filter และพารามิเตอร์ของ request ก่อนลองใหม่

Q. ERPC_GRPC_REQUEST_FAILED หมายความว่าอะไรเมื่อ gRPC ส่งสถานะอื่นที่ไม่ใช่ศูนย์?

Request ล้มเหลวด้วย gRPC status ที่ถูกต้องและ status นั้นกำหนดขั้นตอนถัดไป แก้ request สำหรับ status เช่น OutOfRange (11) เมื่อ history range ไม่ถูกต้อง; back off สำหรับ availability status เช่น Unavailable (14) อย่าจัดทุก status non-zero เป็น transient หรือ retry response เดิมซ้ำ ๆ

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 แบบใดเหมาะสม ระหว่างภูมิภาคเดียว สองภูมิภาค หรือทั่วโลก
รายงานการกระจายตัวของ Solana Mainnet

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
  • หลีกเลี่ยงกับดักของความหน่วงเฉลี่ย: 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 และการเทรด
Validators Solutions - ข้อมูลเครือข่าย Solana
ข้อมูลเครือข่าย 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. ฉันได้รับ error 401 เพราะอะไร?

เพื่อรักษาสภาพแวดล้อมที่มีความหน่วงต่ำ เราจึงใช้การจำกัด IP หากคุณไม่มี subscription หรือ IP ของคุณไม่ได้ลงทะเบียนไว้ คุณจะได้รับ error 401
โปรดตรวจสอบอีกครั้งว่า IP ที่คุณลงทะเบียนตรงกับ IP ที่คุณใช้เข้าถึงในปัจจุบัน

Q. ฉันได้รับ error 429 เพราะอะไร?

คุณใช้งานถึงขีดจำกัดจำนวนการเชื่อมต่อของแผนคุณแล้ว
หากคุณพบ error นี้ โปรดพิจารณาอัปเกรดแผนของคุณ หากคุณต้องการจำนวนการเชื่อมต่อมากกว่าที่แผน premium ของเราให้ได้ dedicated gRPC node จะเหมาะสมกว่า

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 เข้าบัญชีของคุณ
ประเทศที่รองรับ: กรีซ, โครเอเชีย, เช็ก, ไซปรัส, เดนมาร์ก, เนเธอร์แลนด์, บัลแกเรีย, เบลเยียม, โปรตุเกส, โปแลนด์, ฝรั่งเศส, ฟินแลนด์, มอลตา, เยอรมนี, โรมาเนีย, ลักเซมเบิร์ก, ลัตเวีย, ลิทัวเนีย, สเปน, สโลวะเกีย, สโลวีเนีย, สวีเดน, ออสเตรีย, อิตาลี, เอสโตเนีย, ไอร์แลนด์, ฮังการี
สำหรับประเทศที่ไม่อยู่ในรายการ โปรดชำระเงินด้วยบัตรเครดิต
ERPC Web Dashboard

Q. ฉันจะทำให้ได้ความหน่วงต่ำที่สุดเท่าที่จะเป็นไปได้อย่างไร?

เราขอแนะนำอย่างยิ่งให้ใช้ dedicated gRPC node ร่วมกับ เซิร์ฟเวอร์ Bare Metal ของเรา
ทั้งสองอยู่บนเครือข่ายเดียวกัน ทำให้สื่อสารแบบส่วนตัวระยะทางเป็นศูนย์ได้โดยไม่ต้องผ่านอินเทอร์เน็ต การตั้งค่าแบบนี้จะได้ความหน่วงที่ต่ำมาก โดยทั่วไปอยู่ที่ประมาณ ping 0.1ms
โปรดติดต่อเราผ่าน ERPC Web Dashboard สำหรับรายละเอียดเพิ่มเติม
ERPC Web Dashboard
🔗 ERPC Web Dashboard

Q. ความหน่วงเป็นอย่างไร?

ความหน่วงแตกต่างกันไปขึ้นอยู่กับวิธีการวัดและสภาพแวดล้อมการใช้งานเฉพาะของคุณ แทนที่จะมุ่งเน้นที่ค่าตัวเลขที่แน่นอน สิ่งสำคัญคือการทำให้แน่ใจว่าความหน่วงนั้นตรงกับความต้องการในการใช้งานจริงของคุณ
เรามีเครื่องมือที่ใช้งานง่ายทั้งในภาษา TypeScript และ Rust สำหรับการวัดความหน่วง

Q. RPC (gRPC, Shreds) นี้เร็วกว่าเจ้าอื่นไหม?

เราออกแบบทุกระดับราคาโดยให้ความสำคัญกับความเร็ว และยินดีให้มีการวัดเปรียบเทียบแบบเคียงข้างกับผู้ให้บริการรายอื่นใดก็ตาม ผลลัพธ์อาจแตกต่างกันตามภูมิภาค ตามการใช้ shared endpoint หรือ dedicated endpoint ตามโปรโตคอลที่ใช้ (WebSockets, gRPC หรือ Shreds) และตามภาษาโปรแกรมที่ client ของคุณใช้
หากคุณพบว่าบริการของเราช้ากว่า โปรดแจ้งเงื่อนไขที่เจาะจงและคู่แข่งที่คุณนำมาเปรียบเทียบให้เราทราบผ่าน ERPC Web Dashboard เราจะหาสาเหตุและปรับปรุงความเร็วให้ดียิ่งขึ้น
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
ก่อนหน้าตัวอย่างโค้ดถัดไปSolana Shreds / gRPC / เริ่มต้นใช้งานอย่างรวดเร็ว