«لماذا يستمر زمن استجابة ShredStream لديّ في Solana في الازدياد» — الأسباب والحلول

«لماذا يستمر زمن استجابة ShredStream لديّ في Solana في الازدياد» — الأسباب والحلول

«لماذا يستمر زمن استجابة ShredStream لديّ في Solana في الازدياد» — الأسباب والحلول
نتلقى في ERPC باستمرار استفسارات من عملاء يستخدمون تدفق بيانات Solana في الوقت الفعلي، مفادها أن «زمن استجابة ShredStream يزداد تدريجيًا ثم يتوقف في النهاية».
سنشرح في هذا المقال بوضوح الأسباب الرئيسية وراء حدوث هذه المشكلة ونقدم حلولًا ملموسة لتحسين أداء تطبيقك.

لماذا يستمر زمن استجابة ShredStream في الازدياد؟

ينقل ShredStream حاليًا جميع بيانات الوقت الفعلي تقريبًا من دون مرشحات. ولهذا السبب، إذا كانت قدرات المعالجة لدى العميل غير كافية، تتراكم البيانات فيزداد زمن الاستجابة تدريجيًا.
والأسباب الرئيسية هي كما يلي:

1. المعالجة باستخدام Node.js أو البيئات أحادية الخيط

في البداية، بُني عميل ShredStream باستخدام TypeScript وبروتوكول gRPC. غير أن المرشحات لم تُنفَّذ بعد، ولذا فإن استخدام بيئة أحادية الخيط مثل Node.js يبلغ حدود المعالجة بسرعة، مما يجعل زمن الاستجابة يرتفع باستمرار.
وقد تحققنا من أن هذه المشكلة لا تحدث عند استخدام عميل Rust على الجهاز نفسه، مما يؤكد محدودية المعالجة أحادية الخيط.

الحل: تعدد الخيوط باستخدام NAPI-RS

استجابةً لذلك، طورنا حلًا يستخدم تقنية NAPI-RS، مما يتيح المعالجة متعددة الخيوط في Rust مع الحفاظ على التحكم من TypeScript. وهذا الحل، المعروف باسم Solana Stream SDK، مفتوح المصدر ومتاح للجميع:
إذا كنت تستخدم Node.js أو TypeScript، فإننا نوصي بشدة باستخدام حزمة SDK هذه. وللحصول على أقصى أداء، فكر في استخدام لغة أصلية تدعم تعدد الخيوط مثل Rust.

2. عدم كفاية أداء الخادم (لا سيما تردد وحدة المعالجة المركزية)

تعمل تطبيقات التدفق في الوقت الفعلي التي تستخدم Solana ShredStream عادةً على نحو كافٍ على خادم بأربعة أنوية وذاكرة 16GB. غير أن تردد وحدة المعالجة المركزية بالغ الأهمية. فالترددات المنخفضة قد تؤدي إلى ازدياد تدريجي في زمن الاستجابة.
فالخوادم المصممة لتعظيم الربح تستخدم غالبًا وحدات معالجة مركزية من أجيال أقدم أو وحدات كثيرة الأنوية منخفضة التردد. فعلى سبيل المثال، عادةً ما يبلغ التردد الأساسي لوحدات AMD EPYC من الجيل الرابع كثيرة الأنوية (مثل الطرز ذات 84 نواة) نحو 2.2GHz، وكثيرًا ما لا تستفيد من تعزيز التوربو بفاعلية. وبما أن الحد الأدنى الموصى به لمدققي Solana هو 2.8GHz، فإننا ننصح العملاء بشدة باعتماد وحدات معالجة مركزية بهذا التردد على الأقل.
إضافة إلى ذلك، يشيع لدى مزودي VPS استخدام «الالتزام الفائض» (overcommitment)، وهي ممارسة تقسيم خادم مادي واحد إلى خوادم افتراضية متعددة. وفي بيئة الالتزام الفائض، يحدث تنافس على الموارد مع المستخدمين الآخرين بشكل متكرر في أوقات الذروة، مما يؤثر سلبًا في الأداء.

الحل: استخدم VPS بأحدث جيل من وحدات المعالجة المركزية عالية التردد

توفر ERPC خوادم VPS مزودة بأحدث جيل من وحدات المعالجة المركزية AMD EPYC بترددات تصل إلى 4.15GHz. وتحقق هذه الخوادم أداءً قريبًا من حلول bare-metal، وهي ملائمة تمامًا لأعباء عمل Solana التي تتطلب تدفق بيانات في الوقت الفعلي.
سابقًا، لم تكن حلول VPS عالية التردد متاحة، مما أجبر المستخدمين المحتاجين إلى أداء الوقت الفعلي على اختيار خوادم bare-metal. وتعالج عروض VPS من ERPC هذا القيد.

نوصي بخدمة EPYC VPS عالية الأداء لدينا

ERPC VPS
حلول VPS من ERPC محسّنة لتدفق بيانات Solana في الوقت الفعلي وتحظى بإشادة كبيرة من العديد من المتداولين عالي التردد والمشاريع.
وهذه الحلول مثالية للعملاء المحتاجين إلى أداء عالٍ من دون الحاجة إلى موارد خادم bare-metal.
ونشجعكم على تجربة حلول VPS لدينا.
للتجارب المجانية أو الاستشارات التفصيلية، يرجى زيارة خادم Discord الرسمي لـ Validators DAO:
تظل ERPC ملتزمة بمواصلة البحث والتطوير لتلبية احتياجاتكم المتطورة ودعم تحسين الأداء.
شكرًا لدعمكم المتواصل.