FAQ - Geyser gRPC Stream

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

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

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

เมื่อคุณลงทะเบียน IP ของคุณ เราจะ ping จาก gRPC load balancer ทุกตัวเพื่อเลือกภูมิภาคที่ใกล้ที่สุด หากการตอบกลับ ICMP ถูกบล็อกโดยไฟร์วอลล์ของคุณ (ufw, cloud firewall, security group ฯลฯ) ค่าที่วัดได้อาจกลายเป็น 9999ms ซึ่งอาจทําให้ไม่ได้เลือกภูมิภาคที่ใกล้และเหมาะสมที่สุด โปรดเพิ่ม IP ของ load balancer ด้านล่างนี้ลงใน allowlist เพื่อให้ระบบเลือกภูมิภาคที่ใกล้ที่สุดโดยอัตโนมัติ
RegionDomainIP Address
🇳🇱 Amsterdamgrpc-ams1.erpc.global84.32.103.245
🇳🇱 Amsterdamgrpc-ams1.erpc.global84.32.64.77
🇺🇸 New Yorkgrpc-ny6-1.erpc.global64.130.37.222
🇩🇪 Frankfurtgrpc-fra1-1.erpc.global185.191.118.149
🇩🇪 Frankfurtgrpc-fra1-1.erpc.global185.191.118.177
🇩🇪 Frankfurtgrpc-fra1-1.erpc.global185.191.118.206
🇬🇧 Londongrpc-lon6-1.erpc.global67.209.52.250
🇯🇵 Tokyogrpc-tokyo-6.erpc.global198.13.133.88
🇸🇬 Singaporegrpc-sgp6-1.erpc.global202.8.11.52
🇦🇺 Sydneygrpc-syd-1.erpc.global82.26.116.36
🛰️ Far Pointgrpc-far-point.erpc.global63.254.162.14

Q. ฉัน allowlist IP แล้ว แต่ยังเชื่อมต่อไม่ได้ ควรตรวจสอบอะไร?

ERPC gRPC และ Shreds endpoints ใช้ HTTP แบบปกติบน port 80 และป้องกันด้วย IP allowlisting ไม่ได้ใช้ HTTPS/TLS บน port 443
หากคุณคัดลอกตัวอย่าง client จากผู้ให้บริการรายอื่น ตัวอย่างนั้นอาจตั้งค่า :443 หรือ HTTPS เป็นค่าเริ่มต้น การเปลี่ยนแค่ domain อาจทำให้ port และ TLS settings ยังเหมือนเดิม ซึ่งจะทำให้เชื่อมต่อไม่ได้
endpoint ด้านล่างเป็นเพียงตัวอย่าง ให้แทนที่ด้วย endpoint ของคุณเองที่แสดงใน dashboard ใช้งานในรูปแบบ HTTP หรือระบุ port 80 อย่างชัดเจนหาก client ต้องการ host และ port:
gRPC ปกติ
  • ใช้ไม่ได้: grpc-fra1-1.erpc.global:443
  • ใช้ได้: grpc-fra1-1.erpc.global:80
  • รูปแบบ URL ที่ใช้ได้: http://grpc-fra1-1.erpc.global
Burst gRPC
  • ใช้ไม่ได้: grpc-fra1-burst.erpc.global:443
  • ใช้ได้: grpc-fra1-burst.erpc.global:80
  • รูปแบบ URL ที่ใช้ได้: http://grpc-fra1-burst.erpc.global
การยืนยันสิทธิ์อ้างอิงจาก IP address ที่ลงทะเบียนไว้ ไม่ต้องเพิ่ม headers x-token, token หรือ Authorization สำหรับ ERPC gRPC หรือ Shreds endpoints เว้นแต่หน้าผลิตภัณฑ์เฉพาะจะระบุไว้อย่างชัดเจน

คิว. Geyser gRPC Burst คืออะไร?

Geyser gRPC Burst คือชั้นบริการ gRPC แบบใช้ร่วมกันความหน่วงต่ําของ ERPC สําหรับงาน Solana stream ที่ไวต่อความหน่วง โดยให้อินเทอร์เฟซ Yellowstone/Geyser gRPC แบบเดียวกับบริการ gRPC ปกติ ซึ่งรวมถึงการ subscribe account, transaction, slot และ block ในขณะที่ใช้โครงสร้างพื้นฐานเฉพาะภูมิภาคของ Burst
ปัจจุบัน Burst ทํางานในภูมิภาค Frankfurt, Amsterdam, New York, Tokyo และ Singapore ระบบจะเลือกภูมิภาค Burst ที่ดีที่สุดที่พร้อมใช้งานสําหรับ IP ที่คุณลงทะเบียนไว้ โดยอ้างอิงจากการวัดความหน่วงจริง

ถาม: ควรอนุญาต IP ใดสำหรับ Burst gRPC?

การกำหนดเส้นทางของ Burst จะวัด latency จาก IP ของ gRPC load balancer ปกติที่แสดงไว้ด้านบน แล้วแมป region ที่รองรับและใกล้ที่สุดไปยัง endpoint ของ Burst โปรดอนุญาต IP ต้นทาง ping ของ gRPC ปกติเหล่านั้นสำหรับการเลือกตาม latency และอนุญาต IP ของ Burst load balancer ด้านล่าง เพื่อให้ client ของคุณเชื่อมต่อกับ endpoint ของ Burst ที่ถูกเลือกได้
RegionBurst DomainIP Address
🇩🇪 Frankfurtgrpc-fra1-burst.erpc.global64.130.41.234
🇳🇱 Amsterdamgrpc-ams1-burst.erpc.global64.130.55.180
🇺🇸 New Yorkgrpc-ny6-burst.erpc.global64.130.59.217
🇯🇵 Tokyogrpc-tokyo-burst.erpc.global208.91.107.247
🇸🇬 Singaporegrpc-singapore-burst.erpc.global67.209.55.15
หากการตอบกลับ ICMP จาก IP ของ gRPC load balancer ปกติถูกบล็อก dashboard อาจแสดง 9999ms และ Burst อาจ fallback ไปยัง region ที่ไม่เหมาะสมที่สุด การบล็อก IP ของ Burst จะส่งผลต่อการเชื่อมต่อกับ endpoint ของ Burst ที่ถูกเลือก

คิว. Burst เหมือนกับ Direct Shreds หรือ ShredStream หรือไม่?

ไม่เหมือน Burst เป็น Yellowstone/Geyser gRPC แบบเต็มรูปแบบที่ทํางานผ่านอินเทอร์เฟซ gRPC มาตรฐาน เหมาะสําหรับกรณีที่คุณต้องการ stream ของ block, slot, transaction หรือ account จาก gRPC client
Direct Shreds / ShredStream เป็นผลิตภัณฑ์แยกต่างหากที่ใช้ UDP สําหรับข้อมูล shred ดิบ และอาจเหมาะกว่าเมื่อเส้นทางข้อมูล pre-block ที่เร็วที่สุดเท่าที่จะเป็นไปได้คือสิ่งสําคัญลําดับแรก ผลิตภัณฑ์ทั้งสองให้บริการอินเทอร์เฟซและงานที่แตกต่างกัน

คิว. ก่อนหน้านี้ฉันใช้แค่ WebSocket ฉันสามารถใช้ gRPC ได้ไหม? มีตัวอย่างให้ดูไหม?

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

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

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

คิว. มีข้อจํากัดของ filter หรือไม่?

ไม่มี ไม่มีข้อจํากัดในการใช้ filter

คิว. คุณแนะนําภูมิภาคไหน?

ไม่มีภูมิภาคใดที่ดีที่สุดอย่างถาวรเพียงภูมิภาคเดียว Solana เป็นเครือข่ายระดับโลก และ leader validator จะเปลี่ยนไปทุก slot ภูมิภาคที่มี validator มากกว่าและมี stake สูงกว่าจะได้เป็น leader slot บ่อยกว่า ซึ่งช่วยให้ transaction land ได้เร็วขึ้น ข้อแลกเปลี่ยนคือ traffic ที่แข่งขันกันก็จะหนาแน่นอยู่ที่นั่นเช่นกัน ดังนั้นภูมิภาคที่มีคนใช้น้อยกว่าบางครั้งอาจให้ผลลัพธ์ที่ดีกว่า ขึ้นอยู่กับกลยุทธ์ของคุณ
ในทางปฏิบัติ ให้เริ่มต้นด้วยการเลือกภูมิภาคที่มี validator หนาแน่น เช่น Frankfurt หรือชายฝั่งตะวันออกของสหรัฐ เมื่อการมี leader slot อย่างสม่ําเสมอเป็นสิ่งสําคัญที่สุด หรือวางตัวเองให้อยู่ใกล้ validator เป้าหมายที่เจาะจง เมื่อการทํางานด้วยเส้นทางที่สั้นที่สุดเป็นสิ่งสําคัญลําดับแรก ใช้ Validators Solutions เพื่อทําความเข้าใจการกระจายตัวของเครือข่าย Solana สาธารณะ จากนั้นใช้ ERPC Leader Slot API และการวัดผลจริงเพื่อตัดสินใจว่าการ deploy แบบภูมิภาคเดียว สองภูมิภาค หรือทั่วโลกเหมาะสมหรือไม่
Solana Mainnet Distribution Report

คิว. ฉันต้องการความหน่วงประมาณ ~400ms หรือดีกว่านั้น

เพื่อให้ได้ความหน่วงภายในประมาณ 400ms โปรดพิจารณาประเด็นสําคัญเหล่านี้:
  • ทําความเข้าใจค่า Ping อย่างสมจริง: ค่า ping บ่งบอกถึงสภาวะในอุดมคติ และไม่ได้สะท้อนความหน่วงจริงในการสื่อสารแบบ streaming ซึ่งโดยทั่วไปจะมีความหน่วงประมาณ 5 เท่าของค่า ping เช่น ค่า ping 100ms ข้ามทวีปจะส่งผลให้เกิดความหน่วงจริงประมาณ 500ms ดังนั้นจึงต้องตั้งโครงสร้างพื้นฐานไว้ภายในภูมิภาคเดียวกันเพื่อให้ได้ความหน่วง ~400ms
    • ค่า Ping อ้างอิงทั่วไป:
      • เครือข่ายเดียวกัน: ~0.1ms
      • Private Network Interconnect (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) มันให้ข้อมูลแบบเรียลไทม์เกี่ยวกับ leader ที่กําลังจะมาถึง น้ําหนัก stake ตําแหน่งทางภูมิศาสตร์ของ validator และค่า ping อ้างอิง ทําให้คุณสามารถระบุ slot สําหรับการเทรดที่เหมาะสมที่สุดด้วยความหน่วงต่ําที่สุดได้อย่างแม่นยํา ข้อมูลแบบแผนที่สาธารณะและ native RPC API มีประโยชน์สําหรับการมองเห็นเครือข่ายในภาพกว้าง แต่ยังไม่แม่นยําพอสําหรับการกําหนดจังหวะเวลาในการดําเนินการ Leader Slot API เติมเต็มช่องว่างนั้นด้วยความละเอียดที่จําเป็นสําหรับการตัดสินใจเรื่อง routing และการเทรด
Validators Solutions - Solana network data
Solana network data: Validators Solutions

คิว. ฉันจะทําการเทรดแบบ 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 ข้อมูลตําแหน่งทางภูมิศาสตร์ของ validator และค่า ping อ้างอิง ด้วยความแม่นยําที่สูงกว่าแหล่งข้อมูลแบบแผนที่สาธารณะหรือ native RPC API อย่างมาก ทําให้คุณสามารถคาดการณ์ opportunity zone ได้แม่นยํายิ่งขึ้น และดําเนินการเทรดด้วยความหน่วงที่เกือบเป็นศูนย์
  • ใช้ Dedicated Node: หากคุณแข่งขันได้ยาก ให้พิจารณา deploy dedicated node โหนดแบบใช้ร่วมกันจะมีความหน่วงเนื่องจาก traffic จากผู้ใช้รายอื่น จึงไม่แนะนํา ยิ่งไปกว่านั้น การวาง dedicated node ของคุณไว้ในเครือข่ายเดียวกันกับแอปพลิเคชันของคุณจะช่วยลดความหน่วงของเครือข่ายได้อย่างมีนัยสําคัญและปรับประสิทธิภาพให้เหมาะสมที่สุด

คิว. ฉันสามารถใช้ endpoint ที่เจาะจงได้ไหม?

เพื่อรักษาสภาพแวดล้อมที่มีความหน่วงต่ํา ระบบของเราจะเลือกโหนดที่ใกล้ที่สุดที่พร้อมใช้งานโดยอัตโนมัติ หากคุณต้องการใช้ endpoint ที่เจาะจง เราขอแนะนําให้เช่าเซิร์ฟเวอร์ที่อยู่ใกล้ที่สุดกับ endpoint นั้น

คิว. ฉันได้รับ error 401 เพราะอะไร?

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

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

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

คิว. ทําไม dedicated endpoint ถึงเร็วกว่า?

shared endpoint ถูกใช้งานโดยลูกค้าหลายรายที่แชร์ทรัพยากรเดียวกัน เมื่อ traffic เพิ่มขึ้น ความหน่วงก็มักจะเกิดขึ้น ทรัพยากรของเซิร์ฟเวอร์มีขีดจํากัดทางกายภาพ และปริมาณงานที่รองรับได้นั้นมีจํากัด เมื่อมีคําขอจํานวนมากเกินไปเข้ามาในเวลาเดียวกัน ก็ต้องประมวลผลทีละรายการตามลําดับ ซึ่งทําให้เวลาตอบสนองช้าลง
แม้ว่าเราจะใช้มาตรการต่าง ๆ เพื่อปรับประสิทธิภาพให้เหมาะสมแม้บน shared endpoint แต่ด้วย dedicated endpoint คุณจะเป็นผู้ใช้ทรัพยากรเพียงรายเดียว นั่นหมายความว่าคุณจะไม่ได้รับผลกระทบจากผู้ใช้รายอื่นเลย จึงมั่นใจได้ถึงการตอบสนองที่เสถียรและรวดเร็วอย่างสม่ําเสมอ
นอกจากนี้ dedicated endpoint ยังมีตัวเลือกการสื่อสารแบบไม่ใช้ TLS เช่น HTTP โดยการข้าม TLS handshake (ประมาณ 20ms) ทําให้การสื่อสารเร็วยิ่งขึ้นเมื่อเทียบกับ HTTPS

คิว. ราคาขายจะถูกปรับขึ้นไหมหลังจากที่ฉันสมัครแล้ว?

ตราบใดที่ subscription ของคุณยังใช้งานอยู่ ราคาขายที่คุณ lock ไว้ตอนสมัครจะยังคงมีผลต่อไป สภาพแวดล้อมที่รองรับ workload แบบเรียลไทม์ของ Solana ได้นั้นหายากในระดับโลก และเราวางแผนที่จะปรับราคา list ขึ้นตามความต้องการด้านฮาร์ดแวร์และเครือข่ายที่เพิ่มขึ้น การกําหนดค่าที่สเปกสูงกว่าและภูมิภาคที่มีความต้องการสูงจะขายหมดเร็วที่สุด ดังนั้นการ lock ราคาโปรโมชันปัจจุบันจึงเป็นทางเลือกที่คุ้มค่าที่สุดในระยะยาว

คิว. ฉันต้องการชําระเงินด้วย crypto

ตอนนี้สามารถชําระด้วย crypto ได้จาก ERPC Web Dashboard แล้ว คุณสามารถใช้ SOL, USDC หรือ EURC เพื่อซื้อ ERPC Credits ได้
ใช้ ERPC Credits เหล่านี้เพื่อเริ่มหรือใช้งานแผน ERPC ต่อ เปิด dashboard เลือก crypto payment ส่ง transfer จาก wallet ของคุณ แล้ว dashboard จะตรวจสอบ transaction และเพิ่ม credits ให้กับ account ของคุณ

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

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

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

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

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

เราขอแนะนําให้คุณลองทดลองใช้ฟรีของเราและเปรียบเทียบประสิทธิภาพกับบริการอื่น ๆ หากคุณพบว่าบริการของเราช้ากว่า โปรดแจ้งเงื่อนไขที่เจาะจงและคู่แข่งที่คุณนํามาเปรียบเทียบให้เราทราบผ่าน ERPC Web Dashboard เราจะหาสาเหตุและปรับปรุงความเร็วให้ดียิ่งขึ้น
เราพัฒนาเรื่องความหน่วงอย่างต่อเนื่องโดยอ้างอิงจากผลตอบรับของลูกค้า หากคุณต้องการ endpoint ที่เร็วที่สุดเท่าที่จะเป็นไปได้ โปรดแบ่งปันข้อมูลโดยละเอียดกับเรา การให้ตัวชี้วัดที่เจาะจงและเงื่อนไขการเปรียบเทียบกับคู่แข่งจะช่วยให้เราส่งมอบประสิทธิภาพที่เหนือกว่าได้ แนวทางที่ขับเคลื่อนด้วยผลตอบรับนี้ช่วยให้เราพัฒนาบริการของเราได้อย่างสม่ําเสมอเสมอมา

คิว. แผนไหนให้ประสิทธิภาพที่เร็วที่สุด?

โดยทั่วไปแล้ว แผนระดับสูงสุดของเราจะให้ประสิทธิภาพที่เร็วที่สุด เนื่องจากมี CPU ที่เหนือกว่า หน่วยความจําที่มากกว่า และการกําหนดค่าฮาร์ดแวร์ที่แข็งแกร่ง
เรายังมีโซลูชันที่ปรับแต่งได้หากคุณต้องการเซิร์ฟเวอร์ที่ทรงพลังยิ่งขึ้น แต่แผนมาตรฐานของเราก็ออกแบบมาเพื่อมอบอัตราส่วนราคาต่อประสิทธิภาพที่เหมาะสมที่สุด
เรามั่นใจในการมอบประสิทธิภาพระดับโลกในทุกระดับราคา หากคุณพบผู้ให้บริการที่เร็วกว่าในช่วงราคาเดียวกัน โปรดแจ้งให้เราทราบเพื่อที่เราจะได้ตรวจสอบและปรับปรุง

คิว. ฉันกําลังประสบปัญหาความหน่วงสูง ฉันทําอะไรได้บ้าง?

ความหน่วงขึ้นอยู่กับความใกล้ของคุณกับ endpoint เป็นอย่างมาก เราขอแนะนําให้เข้าถึงจากเซิร์ฟเวอร์ที่อยู่ใกล้กับ endpoint ที่ให้มา การเชื่อมต่อที่เร็วที่สุดทําได้ด้วย Bare-Metal server และ บริการ VPS ของเรา

คิว. อันไหนเร็วที่สุด: WebSockets, gRPC หรือ Shreds?

ผลตอบรับจากลูกค้าของเราจัดอันดับความเร็วได้อย่างสม่ําเสมอดังนี้:
Shreds > gRPC > WebSockets
หากคุณพบผลลัพธ์ที่แตกต่างออกไป โปรดแบ่งปันประสบการณ์ของคุณ

คิว. ความหน่วงไม่เป็นไปตามที่ฉันคาดหวัง

ประสิทธิภาพแตกต่างกันไปขึ้นอยู่กับภาษาโปรแกรมที่ใช้ โดยทั่วไปแล้วความเร็วของภาษาจัดอันดับได้ดังนี้:
Rust > Go > TypeScript (JavaScript) > Python
ดูการเปรียบเทียบโดยละเอียดได้ที่:
เพื่อประสิทธิภาพสูงสุด เราขอแนะนําอย่างยิ่งให้ใช้ Rust