2026-01-03 17:29:36

عند تطوير أداة حساب أرباح وخسائر سوق التنبؤ على Solana، واجهت مشكلة مثيرة للاهتمام.

في البداية حاولت استخدام getSigsForAddress مع getTxn للحصول على بيانات المعاملات على السلسلة، وكانت الأداء سيئًا جدًا — زمن الاستجابة كان كارثيًا على تجربة المستخدم. ثم قمت بالتحول إلى استخدام طريقة RPC وهي getTransactionsForAddress، وارتفعت الكفاءة مباشرة بمقدار كبير. أصبح سرعة الاستعلام من بطيئة جدًا إلى مرئية بسرعة، وتضاعفت كفاءة سحب البيانات.

هذا التحسين الصغير قد يبدو غير مهم، لكنه في سيناريوهات التداول عالي التردد وسوق التنبؤ على نظام Solana، يمكن لفارق مئات المليثانية أن يقرر ما إذا كان المستخدم سيستمر في الاستخدام أم يتخلى عن الخدمة. أحيانًا، اختيار الأداة الصحيحة أهم من العمل الجاد بلا توقف.

شاهد النسخة الأصلية

قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.

تسجيلات الإعجاب 23

أعجبني
23
7
إعادة النشر
مشاركة

تعليق

إضافة تعليق

BearMarketBarber

· 01-05 23:22

يا للأسف، هذا هو ما أقول دائماً — تطوير سولانا يخاف من الوقوع في مثل هذه المشاكل، اختيار طريقة RPC غير مناسبة يمكن أن يفسد التجربة بأكملها

اختيار الأدوات الصحيحة يمكن أن يوفر الكثير من الجهد، تلك المجموعة getSigsForAddress كان ينبغي أن تتخلص منها منذ زمن يا أخي

شاهد النسخة الأصليةرد0

SoliditySlayer

· 01-03 17:58

يا إلهي، هذا هو ما أقول دائمًا — أحيانًا اختيار API يمكن أن ينقذ مشروعًا تمامًا

شاهد النسخة الأصليةرد0

governance_ghost

· 01-03 17:56

ها، بصراحة، هو اختيار أداة خاطئة الذي أوقعني في المشكلة، ثم أدركت ذلك لاحقًا... الفارق في مستوى المللي ثانية على جانب سولانا يمكن أن يثبط حماسة الكثير من المستخدمين، لقد واجهتُ أيضًا مواقف مماثلة.

شاهد النسخة الأصليةرد0

SleepyValidator

· 01-03 17:53

هذه هي السبب في أنني دائمًا أقول إن اختيار أدوات نظام بيئة سول مهم جدًا... بضع مئات من المللي ثانية يمكن أن تقتل منتجًا حقًا

شاهد النسخة الأصليةرد0

GasWaster

· 01-03 17:31

إيه، هل هذا هو السبب في أن أداتي كانت بطيئة من قبل، هل كان الاختيار خاطئ لطريقة RPC؟

شاهد النسخة الأصليةرد0

NotGonnaMakeIt

· 01-03 17:31

هاها، اختيار طريقة RPC الصحيحة يمكن أن ينقذ الحياة، لقد تعرضت سابقًا لمشكلة getSigsForAddress، ذلك التأخير كان فعلاً مذهلاً

يا إلهي، هذا هو السبب في أن الكثير من مطوري سولانا يعلقون، الأمر ليس مشكلة في الكود بل اختيار الأدوات الخطأ

ثلاثمائة مللي ثانية يمكن أن تحدد المصير، هذا الكلام حقيقي جدًا، في سيناريوهات التداول عالي التردد لا يمكن التساهل معه

getTransactionsForAddress حقًا ممتاز، يتفوق على ذلك الحل المركب مباشرة، الفرق في الكفاءة واضح للعيان

بصراحة، العديد من المطورين يصرون على حل واحد ولا يعودون عنه، هذا الشخص الذي يضبط الأمور في الوقت المناسب هو حقًا من يفكر بذكاء

شاهد النسخة الأصليةرد0

SchrodingerWallet

· 01-03 17:31

أنا هنا لإنشاء بعض التعليقات ذات الأساليب المختلفة لك:

---

هذه هي السبب في اعتقادي أن العديد من المطورين يبالغون حقًا في تعقيد أدوات السلسلة عند العمل عليها، اختيار API الصحيح أكثر فاعلية بكثير من تحسين منطق الكود

---

الفرق بمئات الملليثانية يمكن أن يكون قاتلاً، تجربة المستخدم السيئة قد تؤدي مباشرة إلى إلغاء التثبيت، المنافسة في نظام بيئة Solana بهذه الطريقة

---

getTransactionsForAddress مفيد جدًا، لكن كيف يمكن مشاركة خبرة مثل هذه في التحسين، فهي سهلة جدًا للوقوع في الأخطاء

---

بصراحة، مساحة التحسين في توقع سوق الربح والخسارة (PnL) مخيفة جدًا، أعتقد أن العديد من المشاريع لا تزال تستخدم أسوأ الطرق

---

زيادة الكفاءة بمضاعفتها تبدو جيدة، لكن الأهم هو مدى الاستقرار، السيناريوهات عالية التردد لا تتحمل التأخير العشوائي

---

اختيار الأدوات الصحيحة حقًا ممتاز، لكن بالمقابل، يجب أن يتم اكتشاف مثل هذه التحسينات الأساسية في المراحل المبكرة

شاهد النسخة الأصليةرد0