متجر التطبيق اللامركزي | مركز Web3 للأحداث والألعاب

المواضيع الرائجة

هذه بعض النتائج المثيرة للاهتمام. من الجيد دائما أن نرى MegaETH يأتي في المقدمة :) لوضع البيانات في بعض السياق ، يتكون زمن الانتقال الشامل لطلب RPC من ثلاثة مكونات: (1) زمن انتقال انتشار سرعة الضوء من / إلى المراقب من / إلى الخادم ، (2) الوقت الذي يستغرقه الخادم للاستيلاء على البيانات المطلوبة ومعالجتها بعد ذلك ، (3) الوقت الذي يستغرقه المراقب لتنزيل الاستجابة. كما ذكرت ، فإن طرق RPC التي يتم اختبارها هي على الجانب الأخف ، سواء من حيث التكلفة الحسابية أو من حيث حجم البيانات. هذا يعني أن التجارب اختبرت بشكل أساسي (1) ، أي زمن انتقال الانتشار بين المراقبين وخوادم RPC. لا تفهموني خطأ - RPCs من MegaETH قوية جدا أيضا في (2) و (3) وسيكون من المثير للاهتمام رؤية التجارب التي تشدد عليها! إذن ، كيف نقوم بضبط زمن انتقال الانتشار؟ في الواقع ، لا يوجد الكثير من المقابض. أولا ، يمكننا نشر خوادم RPC في مناطق جغرافية متعددة ، وتوجيه الطلب تلقائيا إلى أقرب خادم. هذا مثل سلاسل الوجبات السريعة التي تفتح متاجر في كل مكان - يوجد دائما فرع قريب! بتعبير أدق ، فإن وجود خوادم موزعة جغرافيا يقلل من المسافة المادية بين المستخدمين والخوادم. ثانيا ، يمكننا تحسين مخطط الشبكة. حتى إذا كان بين نفس زوج المرسل والمستقبل، يختلف زمن انتقال الانتشار استنادا إلى مسار الشبكة الفعلي الذي تم اجتيازه. على سبيل المثال ، بين الساحل الشرقي للولايات المتحدة وآسيا ، يمكن أن يختلف زمن الوصول بمقدار 2x اعتمادا على ما إذا كانت حزم البيانات تمر عبر المحيط الهادئ أو عبر أوروبا. في بعض الأحيان ، هناك مسارات شبكة متعددة تتبع نفس المسار الجغرافي. بعضها أكثر ازدحاما من البعض الآخر مما يؤدي إلى زمن انتقال أعلى. هذا يشبه وجود طرق سريعة متعددة للاختيار من النقطة أ إلى النقطة ب. جاءت مزايا زمن الوصول التي لاحظتها على الأرجح من تحسين المسار.

MegaETH Official RPC مقابل Thirdweb RPC - زمن انتقال Testnet كنت أرغب في سحب البيانات المباشرة من MegaEth دون الحاجة إلى تشغيل أي بنية تحتية وكنت أبحث عن أسرع طريقة للقيام بذلك. لقد استخدمت "" لتشغيل معيار بسيط لمعرفة كيف يقارن RPC الرسمي ل MegaETH ب RPC تابع لجهة خارجية (Thirdweb). كان الهدف هو التحقق من أيهما سيسحب بيانات جديدة من المستكشف بشكل أسرع من أجزاء مختلفة من العالم. استخدم الاختبار مكالمة RPC "eth_blockNumber" و "eth_getBalance" على شبكة اختبار MegaETH. تصل إلى 27 منطقة AWS عبر 6 قارات ، وترسل الطلبات واحدة تلو الأخرى بفجوة ثانية واحدة. تتبع متوسط زمن الوصول وحالات الفشل و 429 خطأ والطلبات الناجحة وإجمالي مدة الطلب. ها هي النتائج أظهرت جميع النتائج أن MegaETH RPC الرسمي كان أسرع في جميع القارات الست وجميع المناطق ال 27. تراوح زمن انتقال MegaETH من حوالي 126 مللي ثانية إلى 238 مللي ثانية وفقا لهذا الاختبار. بالنسبة إلى Thirdweb ، تراوح زمن الانتقال من حوالي 170 مللي ثانية إلى 381 مللي ثانية. كلاهما كان لهما معدلات فشل منخفضة ولكن MegaETH كان أقل قليلا ، وكانت مدة الطلب الإجمالية أقل باستمرار ل MegaETH. بالنسبة للسياق ، عادة ما تحتوي الشبكات على عدد قليل من المناطق التي يكون فيها RPC التابع لجهة خارجية أسرع. يحتوي كل من Avalanche و Optimism و Ethereum على أمثلة على ذلك في المعايير العامة. انظر - نتائج الانهيار الجليدي C-Chain - نتائج التفاؤل - نتائج Ethereum ضرب MegaETH على Thirdweb في كل مكان ليس نموذجيا. أطروحتي حول سبب ظهور MegaETH Official rpc هي أن الشبكة مضبوطة جيدا من الناحية المعمارية ، وتستخدم جهاز تسلسل واحد في كل مرة. أدعو @NamikMuduroglu @yangl1996 @0xSami_M لمشاركة أفكارهم هذه هي شبكة الاختبار بحيث يمكن أن تتغير الأرقام على الشبكة الرئيسية عندما تكون حركة المرور أثقل. ومع ذلك ، في الوقت الحالي ، إذا كنت بحاجة إلى الطريقة الأسرع والأكثر موثوقية لسحب البيانات من مستكشف MegaETH ، فإن RPC الرسمي هو الخيار الواضح. ملحوظة: أنا لست خبيرا ، tis مجرد نظرية وقد لا تكون دقيقة بنسبة 100٪ لأن البيانات التي تم اختبارها كانت مكالمات خفيفة الوزن ، كما تم التقاط هذه النتائج ، وقد تختلف النتائج إذا كانت البيانات الأكبر متورطة في أوقات مختلفة ، وأخيرا استخدمت RPC ويب ثالث عام ، ويمكن أن يكون هناك أخرى أسرع.

‏‎12.79‏K

الأفضل

المُتصدِّرة

التطبيقات المفضلة