الأسئلة الشائعة - Geyser gRPC Stream
Q. في أي المناطق تقع عقدكم؟
نشغّل حاليًا عقدًا في المناطق التالية:
- Frankfurt (FRA)
- Amsterdam (AMS)
- London (LON)
- New York (NY)
- Tokyo (TY)
- Singapore (SGP)
- Sydney (SYD)
يقيس ERPC زمن الاستجابة الفعلي للشبكة استنادًا إلى مسارات التوجيه الحقيقية، فيختار تلقائيًا المنطقة ذات زمن الاستجابة الأدنى بدلًا من الاعتماد على المسافة المستقيمة. لا يحسّن هذا النهج زمن الاستجابة للمستخدمين الأفراد فحسب، بل يعزز أيضًا كفاءة الشبكة بشكل عام ويقوي مرونة ERPC العالمية ضد الهجمات المحتملة.
إذا لم تختر بيئتك المنطقة المثلى تلقائيًا، فيرجى التواصل معنا عبر ERPC Web Dashboard.
ERPC Web Dashboard: https://dashboard.erpc.global/ar
Q. يظهر زمن الاستجابة 9999ms وتُختار منطقة غير مثلى. ماذا أفعل؟
لاختيار منطقة gRPC، يرسل ERPC فحوصات زمن استجابة ICMP إلى عنوان IP المسجل لديك من مضيفي البروكسي المدرجين أدناه. اسمح بطلبات ICMP echo الواردة من كل عنوان IP مصدر مدرج. إذا حظرها جدار ناري (ufw أو جدار ناري سحابي أو مجموعة أمان وما إلى ذلك)، فقد تصبح القيمة المقاسة
9999ms وقد تُختار منطقة غير مثلى. عناوين IP المتعددة في المنطقة الواحدة هي مضيفو فحص منفصلون؛ وكلها مطلوبة.| منطقة الفحص | عناوين IP مصدر ICMP |
|---|---|
| 🇳🇱 Amsterdam | 82.21.43.34, 151.244.92.36 |
| 🇺🇸 New York | 151.243.244.5 |
| 🇩🇪 Frankfurt | 151.241.178.20, 151.241.178.34, 151.241.178.21 |
| 🇬🇧 London | 151.241.65.4 |
| 🇯🇵 Tokyo | 143.20.238.66 |
| 🇸🇬 Singapore | 151.245.186.2 |
| 🛰️ Far Point | 143.20.238.73 |
Q. أضفت عنوان IP الخاص بي إلى قائمة السماح، لكنني ما زلت غير قادر على الاتصال. ما الذي يجب أن أفحصه؟
استخدم نقطة نهاية HTTPS المشفّرة المحددة في لوحة التحكم. يستخدم HTTPS المنفذ 443، بينما يبقى HTTP على المنفذ 80 الخيار غير المشفّر ذا زمن الاستجابة المنخفض.
يستخدم كلا البروتوكولين قائمة السماح نفسها لعناوين IP المسجّلة. استخدم نقطة النهاية المحددة في لوحة التحكم: HTTPS على 443 وHTTP على 80.
- نقطة نهاية HTTPS: استخدم نقطة النهاية المحددة في لوحة التحكم على المنفذ 443.
- نقطة نهاية HTTP: استخدم نقطة النهاية المحددة في لوحة التحكم على المنفذ 80.
- استخدم عنوان URL الظاهر في لوحة التحكم بصيغة
https://أوhttp://.
تعتمد المصادقة على عنوان IP المسجّل لديك. لا تُضف ترويسات
x-token أو token أو Authorization ما لم تنص صفحة منتج معيّن على ذلك صراحةً.Q. لم أستخدم سوى WebSocket من قبل. هل يمكنني استخدام gRPC؟ هل لديكم أمثلة؟
نعم. يمكنك الاختبار بسرعة والبدء في التطوير مع gRPC باستخدام SLV.
لنقطة نهاية مشتركة يمكنك اختبارها دون رمز، نفّذ:
bash
slv check grpc --endpoint <YOUR_ENDPOINT> --token noneslv check grpc --endpoint <YOUR_ENDPOINT> --token noneاطلع على دليل البدء السريع لـ gRPC لمزيد من التفاصيل.
Q. هل يمكنني تسجيل عنوانَي IP اثنين؟
يمكنك استخدام نقطة نهاية واحدة لكل اشتراك. إذا رغبت في استخدام عنوانَي IP، فيجب عليك الاشتراك في اشتراكين منفصلين.
Q. هل توجد حدود على الفلاتر؟
يستخدم Geyser gRPC المشترك وسائل حماية للاستخدام العادل حتى لا يستهلك تدفق واحد الموارد التي يحتاج إليها عملاء ERPC الآخرون. وبموجب قاعدة Shared الحالية، يُرفض كل تعيين
blocks غير فارغ، حتى طلب الكتل الضيق. يجب أن يتضمن كل فلتر حساب account أو owner أو فلتر cuckoo مدعومًا؛ ولا يكفي memcmp أو dataSize وحدهما.أزل الشكل المرفوض واشترك فقط في البيانات التي يحتاج إليها تطبيقك. قد يفي اشتراك المعاملات أو بيانات تعريف الكتل بالغرض من دون حمل كتلة كاملة. يكون Geyser gRPC المخصص مناسبًا عندما تتجاوز حمولة عمل مشروعة حد Shared للشكل أو الموارد؛ لكنه لا يجعل المعلمات غير الصالحة صالحة ولا يصلح عميلاً بطيئًا.
Q. كيف أجمع خطأ gRPC قبل إعادة الاتصال؟
احتفظ بالخطأ الأول قبل أن تستبدله حلقة إعادة الاتصال. سجّل حالة gRPC ورسالتها من البيانات الوصفية الأولية والـ trailers، مع
x-erpc-error-code وx-erpc-error-reason وx-erpc-doc-url. وعندما تعرض ERPC إيقافًا مؤقتًا، سجّل أيضًا x-erpc-retry-after-seconds وx-erpc-retry-at (بثواني Unix).قد يظهر الخطأ بالشكل
ERPC [STREAM_GUARD_SLOW_READER]: .... ألصق الخطأ المعروض أو رمزه في بحث الأسئلة الشائعة. الشرح المرجعي موجود في الأسئلة الشائعة لـ ERPC gRPC. لا تفترض وصول trailer عندما ينتهي الاتصال مبكرًا.يمكنك أيضًا البحث بعَرَض: مستقبِل بطيء، انقطاع، عرض النطاق، تأخر التسليم، تراكم، إيقاف مؤقت، إعادة محاولة، وسيطة غير صالحة، مورد مستنفد، إذن مرفوض، تسجيل IP، تدفقات كثيرة جدًا، كتل كاملة، أو جميع الحسابات.
Q. ما أخطاء gRPC التي تؤدي إلى إيقاف اتصالي مؤقتًا، ومتى يجب أن يتوقف عميلي عن إعادة الاتصال؟
الإيقاف المؤقت فترة محددة المدة تفرضها ERPC بعد أخطاء معينة. يجب ألا يعيد العميل الاتصال ما دام الإيقاف المؤقت ساريًا.
ما يُحتسب. تُحتسب الأخطاء التالية، وتشترك في مجموعة واحدة من المراحل:
- كل طلب Subscribe ترفضه ERPC بـ
ERPC_GRPC_INVALID_ARGUMENTأوSTREAM_GUARD_SHAPE_BLOCKSأوSTREAM_GUARD_SHAPE_ACCOUNTS_ALL، بما في ذلك الطلب الأول. الخطأ المحتسب الأول هو التحذير، ولا يبدأ أي إيقاف مؤقت. STREAM_GUARD_SLOW_READER. ومع ذلك، إذا نشأ تأخر التسليم من جانب ERPC، تغلق ERPC التدفق من دون احتساب ذلك، ولا يحمل الخطأ أي موعد لإعادة المحاولة.
لا يُحتسب ما يلي: إعادة الاتصال نفسها، ورموز
STREAM_ADMISSION_* الأربعة (STREAM_ADMISSION_LIMIT_REACHED وSTREAM_ADMISSION_IP_NOT_ADMITTED وSTREAM_ADMISSION_SOURCE_UNAVAILABLE وSTREAM_ADMISSION_SNAPSHOT_UNAVAILABLE)، وأي خطأ من الأخطاء المحتسبة يقع أثناء سريان إيقاف مؤقت. والخطأ المحتسب الذي يقع أثناء الإيقاف المؤقت لا يمدد الإيقاف المؤقت ولا يتقدّم إلى المرحلة التالية.المراحل. يتقدّم كل خطأ محتسب مرحلةً واحدة وفق هذا الترتيب، بدءًا من التحذير:
- التحذير: لا إيقاف مؤقت.
- إيقاف مؤقت مدته 60 ثانية.
- إيقاف مؤقت مدته 300 ثانية.
- إيقاف مؤقت مدته 1800 ثانية.
- إيقاف مؤقت مدته 86400 ثانية (24 ساعة). هذه هي المرحلة الأخيرة: فيها يبدأ كل خطأ محتسب إيقافًا مؤقتًا آخر مدته 86400 ثانية.
في مرحلة التحذير، لا يتقدّم الخطأ المحتسب التالي إلى الإيقاف المؤقت الذي مدته 60 ثانية إلا إذا وقع خلال 1 ساعة من التحذير. والخطأ المحتسب الذي يقع بعد أكثر من 1 ساعة من التحذير هو تحذير آخر بلا إيقاف مؤقت، وتسري نافذة 1 ساعة عندئذٍ من هذا التحذير الجديد.
الخطأ المحتسب الذي يقع بعد أقل من 60 ثانية من آخر خطأ احتُسب يُحتسب جزءًا من ذلك الخطأ، ولا يرفع المرحلة.
عودة المراحل إلى التحذير. بعد أن تبدأ المراحل إيقافًا مؤقتًا، لا تعود إلى التحذير إلا بعد 24 ساعة بلا أي خطأ محتسب وبلا أي إيقاف مؤقت، تُقاس من نهاية آخر إيقاف مؤقت؛ والخطأ المحتسب التالي بعد ذلك تحذير بلا إيقاف مؤقت. وحتى ذلك الحين، يبدأ الخطأ المحتسب التالي المرحلة التالية فورًا، من دون تحذير.
إيقاف الخروج. يبدأ
STREAM_GUARD_EGRESS_BUDGET إيقافًا مؤقتًا ثابتًا خاصًا به مدته 600 ثانية. ولا يرفع المرحلة.موضع وقت الانتهاء.
- يحمل الخطأ الذي يبدأ إيقافًا مؤقتًا
Retry after N seconds.والترويستينx-erpc-retry-after-secondsوx-erpc-retry-at(بثواني Unix). ولا يحمل التحذير أي موعد لإعادة المحاولة. - عندما يكون الطلب المرفوض المحتسب هو الذي يبدأ إيقافًا مؤقتًا، يأتي الرد عليه بـ
STREAM_GUARD_SHAPE_REJECT_PENALTYمعResourceExhausted (8)بدلًا من رمزه الخاص. - أثناء إيقاف مؤقت بسبب قارئ بطيء أو خروج، يُرَدّ على إعادة الاتصال بـ
STREAM_GUARD_PENALTY_ACTIVEمع الوقت المتبقي. - أثناء إيقاف مؤقت بدأه طلب مرفوض، يُغلق الاتصال الجديد فورًا بلا حالة gRPC وبلا رمز ERPC. ويمكن أن يُرَدّ مرة أخرى على طلب في اتصال لا يزال مفتوحًا بـ
STREAM_GUARD_SHAPE_REJECT_PENALTYمع الوقت المتبقي قبل إغلاق ذلك الاتصال. وقد لا يرى العميل وقت الانتهاء مرة أخرى أبدًا، لذلك يجب أن يحفظx-erpc-retry-atمن أول خطأ يحمله.
| الرمز | حالة gRPC | هل يبدأ إيقافًا مؤقتًا أو يرفع مرحلته؟ | ما يجب أن يفعله العميل |
|---|---|---|---|
ERPC_GRPC_INVALID_ARGUMENT | InvalidArgument (3) | نعم، عندما يرفض طلب Subscribe. وهو حينئذٍ خطأ محتسب وفق المراحل أعلاه. | أوقف الحلقة ولا تعد إرسال الطلب نفسه. يسرد قسمه الخاص أدناه ما يجب التحقق منه. |
STREAM_GUARD_SHAPE_BLOCKS | PermissionDenied (7) | نعم. إنه خطأ محتسب وفق المراحل أعلاه. | أوقف الحلقة ولا تعد إرسال الطلب نفسه. يسرد قسمه الخاص أدناه ما يجب التحقق منه. |
STREAM_GUARD_SHAPE_ACCOUNTS_ALL | PermissionDenied (7) | نعم. إنه خطأ محتسب وفق المراحل أعلاه. | أوقف الحلقة ولا تعد إرسال الطلب نفسه. يسرد قسمه الخاص أدناه ما يجب التحقق منه. |
STREAM_GUARD_SLOW_READER | ResourceExhausted (8) | نعم. إنه خطأ محتسب وفق المراحل أعلاه. ومع ذلك، إذا نشأ تأخر التسليم من جانب ERPC، تغلق ERPC التدفق من دون احتساب ذلك، ولا يحمل الخطأ أي موعد لإعادة المحاولة. | أوقف الحلقة. يسرد قسمه الخاص أدناه ما يجب التحقق منه. إذا بدأ إيقافًا مؤقتًا، فلا تعد الاتصال قبل الوقت الوارد في x-erpc-retry-at. |
STREAM_GUARD_EGRESS_BUDGET | ResourceExhausted (8) | نعم. يبدأ إيقافًا مؤقتًا ثابتًا مدته 600 ثانية خارج المراحل أعلاه. | لا تعد الاتصال قبل الوقت الوارد في x-erpc-retry-at. يسرد قسمه الخاص أدناه ما يجب التحقق منه. |
STREAM_GUARD_SHAPE_REJECT_PENALTY | ResourceExhausted (8) | نعم. إنه الطلب المرفوض المحتسب الذي بدأ إيقافًا مؤقتًا. ويمكن أن يعود مرة أخرى مع الوقت المتبقي في اتصال لا يزال مفتوحًا. | لا تعد الاتصال قبل الوقت الوارد في x-erpc-retry-at. أصلح الطلب المرفوض ولا تعد إرساله من دون تغيير. |
STREAM_GUARD_PENALTY_ACTIVE | ResourceExhausted (8) | لا. يُبلغ عن إيقاف مؤقت سارٍ بالفعل بسبب قارئ بطيء أو خروج. | لا تعد الاتصال قبل الوقت الوارد في x-erpc-retry-at. |
STREAM_ADMISSION_LIMIT_REACHED | ResourceExhausted (8) | لا. ليس له إيقاف مؤقت محدد بوقت. | أغلق التدفقات غير المستخدمة، ثم أعد المحاولة. |
STREAM_ADMISSION_IP_NOT_ADMITTED | PermissionDenied (7) | لا. ليس له إيقاف مؤقت محدد بوقت. | يسرد قسمه الخاص أدناه ما يجب التحقق منه. |
STREAM_ADMISSION_SOURCE_UNAVAILABLE | Unavailable (14) | لا. ليس له إيقاف مؤقت محدد بوقت. | استخدم backoff كالمعتاد وحاول مرة أخرى بعد مهلة. |
STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE | Unavailable (14) | لا. ليس له إيقاف مؤقت محدد بوقت. | استخدم backoff كالمعتاد وحاول مرة أخرى بعد مهلة. |
ما يجب أن يفعله العميل. عند وقوع خطأ محتسب، أوقف الحلقة، ولا تعد إرسال الطلب نفسه، وأصلحه. أثناء الإيقاف المؤقت، لا تعد الاتصال قبل الوقت الوارد في
x-erpc-retry-at. تُحتسب طلبات Subscribe المرفوضة وفق القواعد أعلاه، ولا تُحتسب إعادة الاتصال.Q. ماذا يعني STREAM_GUARD_SLOW_READER مع ResourceExhausted (8) عند قطع اتصال مستقبِل بطيء؟
لاحظت ERPC لهذا التدفق تقدّمًا غير كافٍ في الكتابة أو تأخرًا في التسليم. لا يكفي تأخر التسليم وحده لتحديد السبب. افحص فقدان الشبكة، وعرض النطاق الفعلي، وقدرة المضيف، وما إذا كان مستهلك التطبيق يواكب التدفق. قلل البيانات المشترك بها وانقل المعالجة خارج حلقة الاستقبال إلى قائمة انتظار محدودة. تتحكم القائمة المحدودة في الذاكرة، لكنها لا تصلح مستهلكًا بطيئًا باستمرار. إذا وفرت ERPC موعدًا لإعادة المحاولة، فانتظره قبل إعادة الاتصال. يشرح السؤال «ما الذي يجعل تدفق gRPC لدي يبقى عند سرعة ثابتة ويتأخر؟» أدناه نافذة الاستقبال وكيف توسّعها في مكتبة العميل لديك.
Q. ما الذي يجعل تدفق gRPC لدي يبقى عند سرعة ثابتة ويتأخر؟
قد تتسبب نافذة استقبال صغيرة في عميلك، أو في شيء يقع بينه وبين ERPC، في قطع التدفق بالرمز
STREAM_GUARD_SLOW_READER وفي الإيقافات المؤقتة التي تليه. تشرح هذه الإجابة ما نافذة الاستقبال، وكيف تعرف ما إذا كانت تحدّ من تدفقك، وكيف توسّعها حسب المكتبة. يعرض السؤال «ما أخطاء gRPC التي تؤدي إلى إيقاف اتصالي مؤقتًا، ومتى يجب أن يتوقف عميلي عن إعادة الاتصال؟» أعلاه المراحل ومددها.ما نافذة الاستقبال. في HTTP/2، يُبلغ المستقبِل المرسِلَ بكمية البيانات التي يجوز إرسالها قبل أن يؤكد المستقبِل الاستلام؛ وهذه الكمية هي نافذة الاستقبال (نافذة flow control في HTTP/2). لا تحمل الرحلة الواحدة ذهابًا وإيابًا أكثر من نافذة واحدة، لذا تبلغ السرعة حدها الأقصى قرب حاصل قسمة النافذة على زمن الذهاب والإياب (الرحلة إلى نقطة النهاية والعودة منها).
الحدود الأخرى. هناك نافذتان، واحدة لكل تدفق وواحدة لكل اتصال (تتشاركها كل التدفقات على الاتصال الواحد)، والأصغر بينهما هي التي تحدد الحد. في مواصفة HTTP/2، تبدأ النافذتان كلتاهما عند 65,535 بايت. ويحدّ مخزن الاستقبال المؤقت في TCP (الذاكرة المخصصة للبيانات الواردة) من السرعة بالطريقة نفسها. ولكل خادم وكيل (proxy) أو موازن تحميل أو بوابة أو VPN أو sidecar يقع بين عميلك وERPC نوافذه ومخازنه المؤقتة الخاصة. فإذا كانت نافذة أو مخزن مؤقت هناك صغيرًا، فإنه يضع سقفًا للتدفق حتى عندما تكون نوافذ عميلك نفسه كبيرة.
كيف يبدو ذلك. يستقر تدفق واحد عند السرعة نفسها تقريبًا مهما كان ازدحام السلسلة، ويزداد تأخر التسليم فيه بثبات. قاست ERPC من موقع يبلغ زمن الذهاب والإياب منه إلى نقطة النهاية Shared في Frankfurt نحو 6 ms، مع تغيير النافذة فقط بين كل تشغيل وآخر:
- نافذة تدفق قدرها 16 KiB: ثابتة قرب 2.7 MB/s (أي 16 KiB مقسومة على 6 ms)؛ وزاد تأخر التسليم بنحو 0.6 ثانية كل ثانية، حتى بلغ 26 ثانية خلال 45 ثانية.
- النافذتان كلتاهما 16 MiB: بلغ الحد الأقصى لتأخر التسليم 14 ms.
إذا نشأ تأخر التسليم من جانب ERPC، تغلق ERPC التدفق من دون احتساب ذلك، ولا يحمل الخطأ أي موعد لإعادة المحاولة.
كيف تتحقق.
- قارن سرعة التدفق وتأخر التسليم فيه بالنمط الموصوف أعلاه.
- قِس زمن الذهاب والإياب. اضرب سرعة التدفق في زمن الذهاب والإياب لتقدير النافذة (مثلًا: 2.7 MB/s مضروبة في 6 ms تساوي نحو 16 KB).
- تحقق مما إذا كانت إحدى نافذتي عميلك مضبوطة على قيمة صغيرة، أو ما إذا كان النمو التلقائي (أي توسيع المكتبة للنافذة بنفسها) معطّلًا.
- تحقق من مخزن الاستقبال المؤقت في TCP. على Linux، شغّل
sysctl net.ipv4.tcp_rmem net.core.rmem_max، وانظر ما إذا كان تطبيقك يضبطSO_RCVBUF، لأن ذلك يعطّل تحديد الحجم التلقائي. - تحقق من النوافذ والمخازن المؤقتة لكل ما يقع بين عميلك وERPC.
- إذا لم يكن للسرعة سقف وكان التأخر وحده يزداد، فالبطء في المعالجة بعد الاستلام. يشرح السؤال «ماذا يعني
STREAM_GUARD_SLOW_READERمعResourceExhausted (8)عند قطع اتصال مستقبِل بطيء؟» أعلاه كيف تقصر حلقة الاستقبال على القراءة وتنقل العمل الثقيل إلى قائمة انتظار محدودة.
الإعدادات حسب المكتبة. تضبط الأمثلة النافذتين كلتيهما على 16 MiB، كما في قياس ERPC. وإذا كانت مكتبتك غير مذكورة هنا، فابحث عن إعدادات النافذة الأولية في HTTP/2.
Rust مع
yellowstone-grpc-client. من دون إعدادات للنافذة، يستخدم GeyserGrpcClient::build_from_shared قيمة 2 MiB لكل تدفق و5 MiB لكل اتصال. عند زمن ذهاب وإياب قدره 6 ms، تسمح هذه القيم الافتراضية بأكثر من 300 MB/s، لذا فهي لا تضع سقفًا للتدفق. ولضبط النافذتين بنفسك، استخدم دالتي الـ builder، وأبقِ 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?;// النافذتان مثبتتان على 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 لكل تدفق، و8 MiB لكل اتصال، والنمو التلقائي مفعّل. تبدأ النافذة عند 64 KiB وتنمو حتى 16 MiB، لذا نادرًا ما تضع القيم الافتراضية سقفًا للتدفق. ولتثبيت الأحجام، مرّر الوسيط الثالث مع grpcHttp2AdaptiveWindow: false.typescript
// النافذة التكيفية معطّلة، لذا تُستخدم هذه الأحجام الثابتة.
const client = new Client(endpoint, undefined, {
grpcInitialStreamWindowSize: 16 * 1024 * 1024,
grpcInitialConnectionWindowSize: 16 * 1024 * 1024,
grpcHttp2AdaptiveWindow: false,
})// النافذة التكيفية معطّلة، لذا تُستخدم هذه الأحجام الثابتة.
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 فيطبّقه على نافذة التدفق وحدها، فتبقى نافذة الاتصال عند 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,
})// يتطلب @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),
)// اضبط الاثنين؛ فهذا يعطّل أيضًا النمو التلقائي للنافذة.
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 القراءة المسبقة لكل تدفق (القيمة الافتراضية 64 KB)؛ وقد تفيد القيم الأكبر مع زمن ذهاب وإياب طويل.python
# إذا تضمنت خياراتك ("grpc.http2.bdp_probe", 0)، فاحذف هذا الإدخال.
channel = grpc.secure_channel(target, creds, options=[
("grpc.http2.lookahead_bytes", 16 * 1024 * 1024),
])# إذا تضمنت خياراتك ("grpc.http2.bdp_probe", 0)، فاحذف هذا الإدخال.
channel = grpc.secure_channel(target, creds, options=[
("grpc.http2.lookahead_bytes", 16 * 1024 * 1024),
])استقبل من مكان أقرب. يتيح زمن الذهاب والإياب الأقصر للنافذة نفسها أن توصل بيانات أكثر، وخدمة VPS وخادم Bare-Metal من ERPC يضعان العميل قرب نقطة النهاية.
قسّم بحذر. تسمح خطة Standard بـ 10 تدفقات وخطة Premium بـ 50، لكل عنوان IP مصدر مسجّل. يحصل كل تدفق على نافذة تدفق خاصة به، لكن التدفقات على الاتصال الواحد تتشارك نافذة اتصال واحدة، لذا تظل نافذة الاتصال الصغيرة تحدّ من السرعة. وعند استبدال تدفق، أغلق القديم أولًا: فالتدفقات المفتوحة تدخل ضمن الحد، وتجاوزه يعيد
STREAM_ADMISSION_LIMIT_REACHED (وله سؤاله الخاص أدناه). ولا يسرّع التقسيم معالجةً بطيئة.Q. ماذا يعني STREAM_GUARD_EGRESS_BUDGET مع ResourceExhausted (8)؟
تجاوزت الحركة الإجمالية من عنوان IP حد Shared، ولذلك قد تُغلق التدفقات المرتبطة معًا. قلل حجم البيانات والتدفقات المتوازية غير الضرورية وانتظر الموعد المعاد. يستمر إيقاف الخروج هذا 600 ثانية ولا يرفع سلم العقوبات، مع أن إيقافًا أطول قائمًا قد يظل نافذًا.
Q. ماذا يعني STREAM_GUARD_PENALTY_ACTIVE مع ResourceExhausted (8)؟
لا يزال إيقاف مؤقت سابق بسبب قارئ بطيء أو خروج ساريًا، وتحمل هذه الاستجابة الوقت المتبقي. احتفظ بخطأ ERPC الأول، وأصلح سببه، ولا تعد الاتصال قبل
x-erpc-retry-at؛ لا تعد الاتصال مبكرًا للاختبار. لا تُحتسب محاولات إعادة الاتصال. يعرض السؤال «ما أخطاء gRPC التي تؤدي إلى إيقاف اتصالي مؤقتًا، ومتى يجب أن يتوقف عميلي عن إعادة الاتصال؟» أعلاه المراحل ومددها.Q. ماذا يعني STREAM_GUARD_SHAPE_BLOCKS مع PermissionDenied (7)؟
ترفض قاعدة Shared الحالية كل تعيين
blocks غير فارغ، حتى عندما يكون الطلب ضيقًا. أزل تعيين blocks. استخدم المعاملات و/أو بيانات تعريف الكتل عندما تفي بالحاجة؛ فلا يكافئ أي منهما كتلة كاملة. تتطلب الكتل الكاملة Geyser gRPC مخصصًا؛ ولا يعني ذلك وجود خطة كتل انتقائية ضمن Shared.Q. ماذا يعني STREAM_GUARD_SHAPE_ACCOUNTS_ALL مع PermissionDenied (7)؟
يجب أن تختار خانة فلتر الحساب البيانات باستخدام
account أو owner أو فلتر cuckoo مدعوم. لا يكفي memcmp وdataSize وحدهما. قيّد طلب الحساب بأحد هذه الأشكال المدعومة أو استخدم Geyser gRPC مخصصًا عندما تحتاج إلى تدفق حسابات كامل.Q. ماذا يعني STREAM_GUARD_SHAPE_REJECT_PENALTY مع ResourceExhausted (8)؟
يعود هذا الرمز بدلًا من
ERPC_GRPC_INVALID_ARGUMENT أو STREAM_GUARD_SHAPE_BLOCKS أو STREAM_GUARD_SHAPE_ACCOUNTS_ALL عندما يكون ذلك الطلب المرفوض المحتسب هو الذي يبدأ إيقافًا مؤقتًا؛ ويوضح السؤال «ما أخطاء gRPC التي تؤدي إلى إيقاف اتصالي مؤقتًا، ومتى يجب أن يتوقف عميلي عن إعادة الاتصال؟» أعلاه متى يحدث ذلك. وهو يحمل Retry after N seconds. وx-erpc-retry-after-seconds وx-erpc-retry-at. أثناء هذا الإيقاف المؤقت، تُغلق الاتصالات الجديدة فورًا بلا حالة gRPC وبلا رمز ERPC، لذلك قد لا يرى العميل وقت الانتهاء مرة أخرى أبدًا. احفظ x-erpc-retry-at من أول خطأ يحمله. تُحتسب طلبات Subscribe المرفوضة وفق القواعد أعلاه، ولا تُحتسب إعادة الاتصال. أصلح الطلب ولا تعد إرساله من دون تغيير. قد يبدو إغلاق الاتصال المبكر كخطأ نقل، لذلك احتفظ بخطأ ERPC الأول قبل أن تخفيه حلقة إعادة الاتصال.Q. ماذا يعني STREAM_ADMISSION_LIMIT_REACHED مع ResourceExhausted (8)؟
سعة القبول ممتلئة حاليًا. أغلق التدفقات غير المستخدمة أو المكررة، وافحص السعة المخصصة للاتصال، ثم أعد المحاولة عند توفر السعة. لا تعني هذه الاستجابة وحدها وجود عقوبة محددة بوقت.
Q. ماذا يعني STREAM_ADMISSION_IP_NOT_ADMITTED مع PermissionDenied (7)؟
لم تتمكن ERPC من قبول الاتصال، بما في ذلك بعد انتهاء فترة سماح تسجيل IP. قارن عنوان IP الصادر الفعلي بالعنوان المسجل وأكد حالة الوصول الحالية. أتح وقتًا لانتشار تغيير التسجيل من دون افتراض مدة ثابتة، واتصل بالدعم إذا استمرت الحالة.
Q. ماذا يعني STREAM_ADMISSION_SOURCE_UNAVAILABLE مع Unavailable (14)؟
لم تتمكن ERPC من تحديد مصدر هذا الاتصال في ذلك الوقت. استخدم backoff وحاول لاحقًا. إذا استمر الأمر، فتواصل مع الدعم مرفقًا الخطأ الأول وبياناته الوصفية؛ فهذه الاستجابة لا تثبت عطلًا في شبكة العميل أو خادمه.
Q. ماذا يعني STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE مع Unavailable (14)؟
لم تتمكن ERPC من التحقق من الوصول في ذلك الوقت. استخدم backoff وحاول لاحقًا، ثم تواصل مع الدعم إذا استمر الأمر. إعادة التسجيل مرارًا أو توسيع الفلاتر أو شراء Geyser gRPC مخصص لا يصلح استجابة التوافر هذه.
Q. ماذا يعني ERPC_GRPC_INVALID_ARGUMENT مع InvalidArgument (3)؟
يحتوي الطلب على معلمات أو خيارات أو أنواع حقول أو مفاتيح أو مجموعات فلاتر غير صالحة. أصلح الطلب قبل إعادة المحاولة، ولا تعد إرسال الطلب نفسه. كل طلب Subscribe يُرفض بهذا الرمز هو خطأ محتسب وفق قواعد الإيقاف المؤقت الواردة في السؤال «ما أخطاء gRPC التي تؤدي إلى إيقاف اتصالي مؤقتًا، ومتى يجب أن يتوقف عميلي عن إعادة الاتصال؟» أعلاه، وهي قواعد مشتركة مع
STREAM_GUARD_SHAPE_BLOCKS وSTREAM_GUARD_SHAPE_ACCOUNTS_ALL وSTREAM_GUARD_SLOW_READER. وعندما يبدأ أحد هذه الطلبات إيقافًا مؤقتًا، يأتي الرد عليه بـ STREAM_GUARD_SHAPE_REJECT_PENALTY مع ResourceExhausted (8). ولا يجعل Geyser gRPC المخصص المعلمات غير الصالحة صالحة.تنهي رسالة الخطأ الرمز بعبارة
(reason: <token>)، ويُعاد الـ token نفسه في ترويسة الاستجابة x-erpc-error-reason. ابحث عن الـ token في الجدول أدناه لمعرفة ما يجب تغييره. وعند وجود حد، تذكره رسالة الخطأ.| Reason | المعنى | ما يجب تغييره |
|---|---|---|
too_many_filters | يحتوي الطلب على فلاتر مسماة أو data slices أكثر مما يسمح به طلب واحد. | استخدم عددًا أقل من الفلاتر المسماة (أو data slices) من هذا النوع في كل طلب. |
empty_filter | لا يحتوي فلتر على أي عنوان، والفلتر الفارغ يعني كل شيء. | أعطِ كل فلتر عنوانًا واحدًا على الأقل (accounts: حساب أو owner؛ المعاملات: قائمة حسابات). لا يخدم Shared gRPC فلترًا فارغًا. |
too_many_addresses | يسرد حقل فلتر واحد عناوين أكثر من اللازم. | استخدم عناوين أقل في حقل الفلتر الواحد؛ وزّعها على عدة فلاتر أو قلّص القائمة. |
address_not_allowed | يذكر فلتر عنوانًا لا يسمح به Shared gRPC. | أزل هذا العنوان عالي الحجم من الفلتر. |
filter_name_too_long | اسم فلتر طويل جدًا. | استخدم أسماء فلاتر أقصر (مفاتيح الـ map). |
invalid_commitment | مستوى commitment غير صالح. | استخدم processed أو confirmed أو finalized. |
invalid_address | يحتوي فلتر على عنوان غير صالح. | اجعل كل عنوان عنوان Solana صالحًا بصيغة base58 (دون سلاسل فارغة أو مسافات أو طول خاطئ). |
invalid_signature | قيمة توقيع المعاملة غير صالحة. | استخدم توقيع معاملة صالحًا بصيغة base58. |
invalid_account_data_filter | فلتر بيانات الحسابات غير صالح. | أصلح فلاتر memcmp وdatasize وبيانات token accounts، وأبقِ عددها ضمن الحد المذكور في الرسالة. |
invalid_data_slice | الـ data slices غير صالحة. | رتّب الـ data slices حسب offset وتجنب تداخلها. |
blocks_include_not_allowed | خيارات اشتراك blocks غير متاحة على Shared gRPC. | احذف blocks واستخدم بدلًا منه اشتراك المعاملات أو اشتراك blocks_meta. |
invalid_token_accounts_mode | وضع token accounts غير صالح. | استخدم ALL (0) أو BALANCE_CHANGED (1). |
invalid_argument | لا ينطبق أي من الأسباب أعلاه. | افحص فلتر الطلب ومعلماته قبل إعادة المحاولة. |
Q. ماذا يعني ERPC_GRPC_REQUEST_FAILED عندما يعيد gRPC حالة أخرى غير صفرية؟
فشل الطلب بحالة gRPC صالحة تحدد الخطوة التالية. أصلح طلبًا بحالة
OutOfRange (11) عندما يكون نطاق السجل غير صالح؛ واستخدم backoff مع حالة توافر مثل Unavailable (14). لا تصنف كل حالة غير صفرية على أنها مؤقتة ولا تعيد كل استجابة من دون تغيير.Q. أي منطقة تنصحون بها؟
لا توجد منطقة واحدة مثلى دائمًا. Solana شبكة عالمية، ويتناوب دور القائد بين المدققين سلوتًا بعد سلوت. المناطق التي تضم عددًا أكبر من المدققين وحصة أعلى تشهد سلوتات قيادة بوتيرة أكبر، مما قد يساعد المعاملات على الوصول بشكل أسرع. لكن في المقابل، تتمركز حركة المرور المنافسة هناك أيضًا، لذا قد تحقق منطقة أقل ازدحامًا نتائج أفضل أحيانًا بحسب استراتيجيتك.
كنقطة بداية عملية، اختر منطقة كثيفة المدققين مثل فرانكفورت أو الساحل الشرقي للولايات المتحدة عندما يكون توفر سلوتات القيادة بثبات هو الأهم، أو ضع نفسك بالقرب من مدقق مستهدف محدد عندما يكون التنفيذ بأقصر مسار هو الأولوية. استخدم Validators Solutions لفهم التوزيع العام لشبكة Solana، ثم استخدم ERPC Leader Slot API والقياسات الفعلية لتقرير ما إذا كان النشر في منطقة واحدة أو منطقتين أو عالميًا هو الأنسب.
Q. أحتاج إلى زمن استجابة قدره ~400ms كحد أقصى أو أفضل من ذلك.
لتحقيق زمن استجابة في حدود 400ms تقريبًا، ضع هذه النقاط الأساسية في الحسبان:
-
فهم واقعي لقيم البينغ: تشير قيم البينغ إلى ظروف مثالية ولا تعكس زمن الاستجابة الفعلي في اتصالات البث، التي تبلغ عادة نحو 5 أضعاف زمن البينغ. على سبيل المثال، بينغ بقيمة 100ms عبر القارات ينتج عنه واقعيًا زمن استجابة يقارب 500ms. لذا يجب إنشاء البنية التحتية داخل المنطقة نفسها لتحقيق زمن استجابة ~400ms.
- مرجع نموذجي لقيم البينغ:
- الشبكة نفسها: ~0.1ms
- الربط البيني للشبكات الخاصة (PNI): ~0.2ms
- مركز البيانات نفسه: ~0.3ms
- المدينة نفسها: ~1ms
- بلد مجاور: ~5–10ms
- بين القارات: ~100–300ms
- مرجع نموذجي لقيم البينغ:
-
تجنب فخ متوسط زمن الاستجابة: مدققو Solana موزعون جغرافيًا حول العالم، ويتغير جدول القائد عشوائيًا مع كل إيبوك. الاعتماد على متوسط زمن الاستجابة لتحقيق ~400ms أمر غير عملي. بدلًا من ذلك، يجب أن تتتبع بدقة جداول المدققين في منطقتك المحددة لتحديد السلوتات ذات زمن الاستجابة الأدنى. ولتحقيق الحد الأدنى من زمن الاستجابة باستمرار، يلزم وجود بنية تحتية في جميع المناطق ذات الصلة. فداخل المنطقة نفسها، يمكن أن يتم الحصول على البيانات خلال عشرات المللي ثانية، مع إمكانية الإرسال في بضع مللي ثانية فقط.
-
تتبع جدول القائد: راقب جدول المدقق القائد لمنطقتك باستخدام ERPC Leader Slot API (
getLeaderSlots). تُعيد جدول القادة القادم ووزن الحصة للإيبوك الحالي والمواقع الجغرافية التقديرية للمدققين وقيم البينغ المرجعية، مما يتيح لك تحديد السلوتات ذات أدنى زمن استجابة التي ينبغي استهدافها قبل حلولها. بيانات الخرائط العامة وواجهات RPC الأصلية مفيدة لرؤية واسعة للشبكة، لكنها ليست دقيقة بما يكفي لتوقيت التنفيذ. تسد Leader Slot API هذه الفجوة بالتفصيل اللازم لقرارات التوجيه والتداول.
بيانات شبكة Solana: Validators Solutions
Q. كيف يمكنني تحقيق تداول الكتلة الصفرية (السلوت الصفري)؟
يتطلب تحقيق تداول الكتلة الصفرية (السلوت الصفري) بنجاح استراتيجيات أكثر تطورًا، كما يلي:
-
تحديد مناطق الفرص: مدققو Solana موزعون حول العالم، ومن المستحيل فيزيائيًا تحقيق زمن استجابة مثالي لكل سلوت. لذلك، راقب جداول قيادة المدققين في المنطقة التي توجد فيها بنيتك التحتية وحدد مناطق الفرص الأكثر ملاءمة. وقد يكون نشر البنية التحتية عبر مناطق متعددة مفيدًا أيضًا. فعلى سبيل المثال، تُعد فرانكفورت منطقة رئيسية بفضل كثافة المدققين العالية فيها، مما يؤدي إلى اختيار القائد بوتيرة أكبر وفرص تداول أكثر.استخدم ERPC Leader Slot API (
getLeaderSlots) للاطلاع على جدول القادة القادم ووزن الحصة للإيبوك الحالي وبيانات الموقع الجغرافي التقديرية للمدققين وقيم البينغ المرجعية بدقة أعلى بكثير من مصادر بيانات الخرائط العامة أو واجهات RPC الأصلية. يتيح لك ذلك تحديد مناطق الفرص قبل حلول السلوتات وتنفيذ صفقات بزمن استجابة شبه معدوم. -
تطبيق العقد المخصصة: إذا كنت تجد صعوبة في المنافسة، ففكر في نشر عقد مخصصة. تعاني العقد المشتركة من زمن استجابة بسبب حركة المستخدمين الآخرين، وبالتالي لا يُنصح بها. علاوة على ذلك، فإن وضع عقدتك المخصصة داخل الشبكة نفسها مع تطبيقك يقلل زمن استجابة الشبكة بشكل كبير ويحسّن الأداء.
Q. هل يمكنني استخدام نقطة نهاية محددة؟
للحفاظ على بيئة منخفضة زمن الاستجابة، يختار نظامنا تلقائيًا أقرب عقدة متاحة. إذا رغبت في استخدام نقطة نهاية محددة، فنوصي باستئجار خادم يقع في أقرب موقع من نقطة النهاية تلك.
Q. أواجه خطأ 401. لماذا؟
للحفاظ على بيئة منخفضة زمن الاستجابة، نطبق قيودًا على عناوين IP. إذا لم يكن لديك اشتراك أو لم يكن عنوان IP الخاص بك مسجلًا، فستتلقى خطأ 401.
يرجى التحقق مرة أخرى من أن عنوان IP المسجل لديك يطابق عنوان IP الذي تصل منه حاليًا.
Q. أواجه خطأ 429. لماذا؟
لقد بلغت حد الاتصالات في خطتك.
إذا واجهت هذا الخطأ، ففكر في ترقية خطتك. وإذا كنت تحتاج إلى اتصالات أكثر مما توفره خطتنا المميزة، فستكون عقدة gRPC مخصصة أنسب.
Q. لماذا نقاط النهاية المخصصة أسرع؟
تُستخدم نقاط النهاية المشتركة من قبل عدة عملاء يتشاركون الموارد نفسها. ومع ازدياد حركة المرور، يميل زمن الاستجابة إلى الارتفاع. موارد الخادم لها حدود فيزيائية، وحجم العمل الذي يمكنها معالجته محدود. وعندما تصل طلبات كثيرة جدًا في الوقت نفسه، يجب معالجتها تسلسليًا، مما يؤدي إلى أوقات استجابة أبطأ.
وعلى الرغم من أننا نتخذ تدابير مختلفة لتحسين الأداء حتى على نقاط النهاية المشتركة، فإنك مع نقاط النهاية المخصصة تكون المستخدم الوحيد للمورد. هذا يعني أنك غير متأثر إطلاقًا بالمستخدمين الآخرين، مما يضمن استجابات مستقرة وسريعة باستمرار.
بالإضافة إلى ذلك، توفر نقاط النهاية المخصصة خيارات اتصال بدون TLS، مثل HTTP. وبتخطي مصافحة TLS (حوالي 20ms)، يصبح الاتصال أسرع مقارنةً بـ HTTPS.
Q. هل سيرتفع سعر العرض بعد اشتراكي؟
طالما ظل اشتراكك نشطًا، يظل سعر العرض الذي ثبّتَّه عند التسجيل ساريًا. البيئات القادرة على الصمود تحت عبء عمل Solana اللحظي نادرة عالميًا، ونعتزم رفع الأسعار المعلنة تدريجيًا بما يتماشى مع الطلب المتنامي على العتاد والشبكة. التكوينات الأعلى مواصفات والمناطق الأكثر طلبًا تنفد أسرع، لذا فإن تثبيت السعر الترويجي الحالي هو الخيار الأكثر كفاءة من حيث التكلفة على المدى الطويل.
Q. أريد الدفع بالعملات المشفرة
تتوفر المدفوعات بالعملات المشفرة من ERPC Web Dashboard عندما تكون دولة عنوان الفوترة المسجل لديك إحدى دول الاتحاد الأوروبي الأعضاء. إذا كانت جميع بطاقات الدفع المسجلة في حسابك صادرة خارج الاتحاد الأوروبي، فلا تتوفر المدفوعات بالعملات المشفرة. يمكنك استخدام SOL أو USDC أو EURC لشراء أرصدة ERPC.
استخدم أرصدة ERPC تلك لتفعيل خطط ERPC أو مواصلتها. افتح لوحة التحكم، واختر الدفع بالعملات المشفرة، وأرسل التحويل من محفظتك، وستتحقق لوحة التحكم من المعاملة وتضيف الأرصدة إلى حسابك.
الدول المدعومة: النمسا، بلجيكا، بلغاريا، كرواتيا، قبرص، تشيكيا، الدنمارك، إستونيا، فنلندا، فرنسا، ألمانيا، اليونان، المجر، أيرلندا، إيطاليا، لاتفيا، ليتوانيا، لوكسمبورغ، مالطا، هولندا، بولندا، البرتغال، رومانيا، سلوفاكيا، سلوفينيا، إسبانيا، السويد.
للدول غير المدرجة في القائمة، يرجى الدفع ببطاقة ائتمان.
Q. كيف يمكنني تحقيق أدنى زمن استجابة ممكن؟
نوصي بشدة بدمج عقدة gRPC مخصصة مع خادم Bare-Metal الخاص بنا.
كلاهما يتشاركان الشبكة نفسها، مما يتيح اتصالًا خاصًا بمسافة صفرية دون المرور عبر الإنترنت. يحقق هذا الإعداد زمن استجابة منخفضًا للغاية، عادةً حوالي 0.1ms بينغ.
يرجى التواصل معنا عبر ERPC Web Dashboard لمزيد من التفاصيل.
Q. كيف هو زمن الاستجابة؟
يختلف زمن الاستجابة بحسب طريقة القياس وبيئة الاستخدام الخاصة بك. وبدلًا من التركيز على القيم الرقمية الدقيقة، من الأهم التأكد من أن زمن الاستجابة يلبي متطلباتك التشغيلية الفعلية.
نوفر أدوات سهلة الاستخدام بلغتي TypeScript وRust لقياس زمن الاستجابة.
Q. هل خدمة RPC (gRPC, Shreds) هذه أسرع من غيرها؟
نحن نصمّم كل فئة سعرية من أجل السرعة، ويسعدنا أن يُقاس ذلك جنبًا إلى جنب مع أي مزوّد آخر. وقد تختلف النتائج بحسب المنطقة، وبحسب ما إذا كنت تستخدم نقطة نهاية مشتركة أو مخصّصة، والبروتوكول المستخدم (WebSockets أو gRPC أو Shreds)، ولغة البرمجة التي يعمل بها عميلك.
إذا وجدت خدمتنا أبطأ، فيرجى إخبارنا بالظروف المحددة والمنافسين الذين قارنتها بهم عبر ERPC Web Dashboard. سنحدد السبب ونحسّن السرعة أكثر.
Q. أي خطة تقدم أسرع أداء؟
بشكل عام، توفر خطتنا الأعلى فئة أسرع أداء بفضل وحدات معالجة مركزية متفوقة وسعات ذاكرة أعلى وتكوينات عتاد قوية.
كما نقدم حلولًا مخصصة إذا كنت تحتاج إلى خوادم أقوى، لكن خططنا القياسية مصممة لتقديم أفضل نسبة سعر إلى أداء.
نحن واثقون من تقديم أداء عالمي المستوى عند كل مستوى سعري. إذا وجدت مزودًا أسرع ضمن النطاق السعري نفسه، فيرجى إخبارنا لنحقق في الأمر ونجري التحسينات.
Q. أواجه زمن استجابة مرتفعًا. ماذا يمكنني أن أفعل؟
يعتمد زمن الاستجابة بشكل كبير على قربك من نقطة النهاية. نوصي بالوصول من خادم قريب من نقطة النهاية الموفَّرة. وتتحقق أسرع الاتصالات مع خادم Bare-Metal وخدمة VPS لدينا.
Q. ما الأسرع: WebSockets أم gRPC أم Shreds؟
تصنّف ملاحظات عملائنا السرعة باستمرار كما يلي:
Shreds > gRPC > WebSockets
يرجى مشاركة تجربتك إذا لاحظت نتائج مختلفة.
Q. زمن الاستجابة ليس كما توقعت.
يختلف الأداء بحسب لغة البرمجة المستخدمة. وبشكل عام، تترتب اللغات من حيث السرعة كما يلي:
Rust > Go > TypeScript (JavaScript) > Python
للمقارنات التفصيلية، راجع:
للحصول على أقصى أداء، نوصي بشدة باستخدام Rust.