مرحباً، أولاً وقبل كل شيء، شكراً جزيلاً لك على واجهة إدارة الاستطلاع الجديد لـ RSS. لقد أحدثت فرقاً كبيراً!
لدينا موقع يحتوي على عشرات قنوات RSS. لاحظت في Sidekiq أن بعض المهام لبعض القنوات قد تستغرق عشرين دقيقة أو أكثر. وهذا يعطّل الطابور بسهولة.
يوجد إعداد باسم RSS polling feed request timeout لكن هذا ليس هو المشكلة. القناة متاحة بسرعة وتُحمَّل بسرعة (على الأقل عندما أجرب ذلك بتصفحي في الوقت نفسه الذي تتعثر فيه Sidekiq مع القناة نفسها). يبدو أن المشكلة تكمن في أن بعض قنوات RSS تحتوي على جميع حلقات البودكاست (على عكس مجرد أحدث 10-15 حلقة) وأن Discourse يبدو أنه يعالج جميع هذه المدخلات حتى لو كانت الحلقات قد تم تنزيلها مسبقاً ولم يطرأ عليها أي تغيير. في الأساس، يمكن أن تتعثر Sidekiq بسهولة لمدة نصف ساعة أو أكثر بسبب قنوات RSS لا تجلب أي تغييرات أو حلقات جديدة.
في المثالي، يجب أن تكتشف Discourse بسرعة أنه لا توجد تغييرات ثم تنتقل إلى ما هو التالي.
اختيارياً، يمكن أن يكون هناك إعداد لتقييد القراءة لأول NN مدخلات في القناة.
أو على الأقل، حد زمني لإنهاء الاستطلاع إذا لم يُحل بعد NN دقيقة (5 دقائق، أو 10 كحد أقصى).
أتساءل عما يحدث بالضبط عندما يستغرق معالجة القناة أكثر من 10 دقائق بينما تكون Sidekiq مشغولة بنسبة 100%. ما الذي يمكن أن يستغرق كل هذا الوقت ويكون مرهقاً جداً للمعالجة؟
هل تعتقد أن هذا شيء يمكن تحسينه في الإضافة الحالية؟
سأكون سعيدًا بالتحسين، هل يمكنك مشاركة رابط تغذيتك (feed) حتى أتمكن من الاختبار محليًا بشكل أفضل؟ (لا تتردد في إرسال رسالة خاصة إذا كنت تفضل إبقاء الأمر سريًا)
شكرًا جزيلًا لك يا @zogstrip على ردك السريع! قنوات RSS عامة، بل إننا ننصح بها لكل من يحب الاستماع إلى البودكاست والبرامج الإذاعية المستقلة باللغة الإسبانية.
العديد منها يستخدم ووردبريس، ويمكننا طلب تعديل عدد المدخلات في قنوات RSS لديهم. لكن كثيرين يستخدمون iVoox، وهي منصة شائعة على الأقل في البلدان الناطقة بالإسبانية. فهم يشحنون جميع حلقات البرنامج في قناتهم RSS، وهم شركة (نسبيًا) كبيرة، ومن الصعب حتى العثور على رابط “تواصل معنا” يؤدي إلى شخص حقيقي. لذلك نحن عالقون هناك. لاختبارك، سأبدأ بإضافة قنوات iVoox، ثم أنتقل إلى المزيد إذا أردت المزيد.
أنا سعيد جدًا بمساهمتنا الصغيرة في الإبلاغ عن هذه المشكلة. ورغم أن حالتنا تبدو حالة نادرة (كما أظن؟)، فإن الحل سيساهم، ولو بدرجة أقل، في تحسين أداء أي نسخة من Discourse تستخدم هذا الإضافة تقريبًا.
أرى أن التصحيحات قد تم دمجها. هل هذا يعني أنه يمكننا الحصول عليها الآن من خلال تحديث Discourse؟
يُشير مصطلح “مدمج” (Merged) إلى أن التغييرات أصبحت موجودة في فرع main. عادةً، لا تتتبع المنتديات الفرع الرئيسي main؛ بل تتتبع بدلاً من ذلك فرع latest. هذا يعني أنه بعد الدمج، لا يزال عليك الانتظار حتى تُنفَّذ الاختبارات التلقائية وتنجح.
عند تصفح Commits · discourse/discourse · GitHub، يمكنك ملاحظة أن هذا حدث للتو مع التزامات (commits) الخاصة بـ zogstrip (يوجد علامة صح خضراء، بينما لا يزال الالتزام الذي يسبقها يحمل النقطة البنية).
لقد أعددت تفعيل موجزات RSS، وقد اكتملت أول جولة من موجزات RSS في الغالب. ظهرت 86 منشورًا جديدًا، كثير منها يعود إلى أيام مضت، مما يعني أن عدة موجزات لم تتمكن من إتمام عملياتها سابقًا، لكنها فعلت ذلك الآن. ممتاز!
لا تزال الموجزات الطويلة جدًا قادرة على إبقاء مهمة مشغولة لفترة طويلة، لكنني لم أرَ سوى ثلاث تجاوزت 10 دقائق. هذا الموجز لا يزال قيد التشغيل بعد مرور ساعة… لكنه طويل حقًا، لذا ربما يكون ذلك مبررًا؟ من ناحية أخرى، فإن احتفاظ موجز واحد بمهمة لفترة طويلة جدًا يُعد مشكلة في حد ذاته. ربما يعود السبب إلى أنه أول استيراد كامل منذ فترة؟ سأتحقق مرة أخرى في جولة RSS التالية (لقد ضبطناها على 180 دقيقة).
ربما تكون هذه المهمة التي تعمل منذ ساعة عالقة على شيء يتجاوز عملية الاستيراد؟ لقد لاحظت للتو أن جميع منشورات ذلك المصدر (feed) يبدو أنها تم استيرادها، مع الصور وكل شيء. على الأقل من وجهة نظر المستخدم، يبدو أن الاستيراد قد اكتمل. ربما يكون هذا حالة شاذة. سأُبلغ مرة أخرى بعد جولات RSS إضافية.
هل هذه الموجزات “جديدة” أم هل تم استيرادها جميعًا بالفعل؟ لم أفعل الكثير فيما يتعلق بتحسين سرعة الاستيراد الأولي، لأن هذا مقيد إلى حد كبير بمدى “سرعة” إنشاء موضوع جديد.
حسنًا، لقد غيّرنا تردد الفحص إلى 10 دقائق لأغراض الاختبار (سنعيده إلى 180 دقيقة، وهو ما يناسبنا تمامًا). بعد إصلاح zogstrip، يتم معالجة معظم المصادر خلال دقيقة أو أقل. هناك فقط بضعة مصادر طويلة جدًا قد تستغرق دقيقتين أو أكثر، لكنها لا تتجاوز أبدًا (ما لم ألاحظ) خمس دقائق. مصدر RSS هذا هو الوحيد الذي يستغرق بشكل موثوق 4 دقائق أو أكثر، لكنه طويل للغاية، لذا لست متأكدًا مما يمكن فعله بشأن هذا السيناريو. حتى المتصفح يحتاج إلى وقت ليعرضه فقط. (وقد نزيله لأسباب غير ذات صلة.)
إن حقيقة أن عملية الفحص بأكملها لا تستغرق أكثر من 5-6 دقائق أمر مذهل. إنها تحسين هائل. بالنسبة لي، يمكن حل هذا التقرير. شكرًا جزيلاً مرة أخرى، @zogstrip.
