ملاحظة: لست متأكدًا مما إذا كانت هذه مشكلة في Discourse. لقد حاولت جمع الأدلة اللازمة، وحتى الآن لم أجد أي شيء يشير إلى أن المشكلة تعود للبنية التحتية أو الإعدادات الخاصة بنا. إعداداتنا في Tappara.co هي أبسط ما يمكن.
الظاهرة الملاحظة:
مواضيع النقاش السريع الشبيهة بالدردشة تتوقف عن التحديث تلقائيًا. بعد تأخير يتراوح بين 30 و180 ثانية، يستأنف التحديث عادةً، ليكشف عن المنشورات التي تم نشرها أثناء التوقف.
ما نعرفه حتى الآن:
لم نلاحظ هذه المشكلة في الموسم السابق، حيث كانت آخر مباراة تُقام في مارس.
نستخدم الفرع المستقر (stable branch) وقمنا بأحدث تحديث رئيسي في أغسطس.
تم الإبلاغ عن المشكلة فورًا في المباريات الاستعراضية الأولى، رغم أن حركة المرور والنشاط كانت متوسطة.
تؤثر المشكلة على متصفح Chrome على أجهزة iOS وAndroid، لكنها أقل تكرارًا على أجهزة Chromebook.
أثناء كتابتي لهذا النص، ألاحظ تجمّدات على هاتفي المحمول بنظام Android، بينما يسير النقاض بسلاسة كما هو متوقع على جهاز Chromebook. جهازان مختلفان على نفس الشبكة.
التجربة تختلف من مستخدم إلى آخر ومن عميل إلى آخر. يبلغ مستخدمون مختلفون عن التجمّدات في أوقات مختلفة. بشكل عام، سُلّطنا ما يقرب من 300 رسالة خلال حوالي 30 دقيقة، وأبلغ المستخدمون عن عشرات حالات التجمّد. يبدو أن التجمّدات تتزامن في الغالب مع أحداث المباراة (الأهداف، العقوبات).
الأمور التي جربت استبعادها:
CloudFlare: أجرينا مباراة واحدة دون استخدام التخزين المؤقت من CloudFlare، واستمرت المشكلة.
الحمل الزائد على المعالج: استخدام المعالج ضمن الحدود المسموح بها، ويتراوح عادةً بين 20-30%.
امتلاء القرص: يبدو أن عمليات إدخال/إخراج القرص ضمن الحدود المسموح بها. نستخدم أقراص SSD من نوع MaxIOPS المقدمة من UpCloud.
معلومات أخرى:
كان مفتش Chrome قيد التشغيل أثناء المباراة، وسُجّلت بعض أخطاء 429، لكن بالنسبة لي لم تكن مرتبطة بالتجمّد.
لا يتلقى المستخدمون النهائيون إشعارات بشأن أخطاء 429 (التباطؤ) أو الحمل الشديد. يتجمّد التحديث ببساطة، ثم يستأنف بعد ذلك. هل تغيرت حدود معدل الطلبات مؤخرًا؟ لدي انطباع بأن حدود المعدل يجب أن تُفعّل إشعارًا في واجهة المستخدم؟
هذه مشكلة مزعجة للغاية، وتؤثر سلبًا بشكل كبير على غرف الدردشة المباشرة أثناء المباريات. نحن ندير هذه الفعاليات منذ سنوات، ولم أرَ مثل هذه المشكلة من قبل.
لقد وصلنا بالفعل إلى 11 من “يونيكورن” على خادم VPS بستة أنوية. كما ذكرنا، لم يحدث هذا أبدًا خلال الموسم السابق الذي كان في مارس الماضي. يحدث الآن حتى مع حركة مرور متوسطة. كما أن هذه المشكلة تظهر بكثرة أكبر على الأجهزة المحمولة، خاصة متصفح Chrome على نظام أندرويد، مقارنةً بالأجهزة المكتبية.
علاوة على ذلك، استطعنا سابقًا استهلاك وحدة المعالجة المركزية بالكامل (في موعد انتهاء مهنة نقل اللاعبين).
لقد غاب عني مباراة أثناء مراقبة الخادم والتلاعب بإعداداته. قمنا بمضاعفة معاملات web.ratelimited، لكن ذلك لم يحل المشكلة.
أداة Inspector تلتقط عددًا من أخطاء 429:
1. عنوان الطلب:
https://tappara.co/message-bus/3ed86765a67f4c31ba4053a0352ecaf5/poll
2. طريقة الطلب:
POST
3. رمز الحالة:
429
المباراة القادمة غدًا، لذا يمكنني تجربة “يونيكورن”. إلى أي مدى يمكننا الصعود؟ هل تغير هذا مع أحدث تحديث رئيسي؟
تعديل:
لقد راجعت الإحصائيات، ووجدت أن نشاطنا حتى الآن أقل مما شهدناه في الربيع (عدد مشاهدات الصفحات، والمستخدمين). عدد المنشورات في دردشة المباراة متطابق (حوالي 900-1000 منشور كل 3 ساعات).
لذلك، لسبب غير معروف، لا نتمكن حاليًا من خدمة نفس الجمهور الذي خدمناه في مارس.
@falco عدد الكركدنات ليس بالتأكيد هو المفتاح. قمت بزيادتها إلى 15 ليلية اليوم. كان موضوع اللعبة هادئًا، مع 700 رسالة فقط، لكن لوحظ تجمد مستمر. كان حمل المعالج خفيفًا، بين 5-25%.
كلما بحثت أكثر في هذا الأمر، بدا أكثر احتمالًا أنه مشكلة وتراجع، لكن مهاراتي ليست كافية لتحديد مكانها.
أعتقد أن هناك خطأً في العميل يتسبب في توقف التحديث تقريبًا بعد حدوث خطأ واحد. اشتباهي هو أن سبب ما تواجهه هو تعرض مستخدميك للحد من المعدل (rate limiting).
سأقوم هذا الأسبوع بالتحقيق في جعل العميل أكثر متانة، وكما ذكرت سابقًا، هذا كود معقد ويتطلب وقتًا.
أدى تصحيح هذه المشكلة إلى جعلني أفكر في تجربة المستخدم (UX) للنقاشات شبه الفورية بشكل عام. تتعامل العديد من المجتمعات مع أحداث واقعية، مما يدفع النقاش بطبيعته نحو محادثة سريعة تشبه الدردشة. قد يكون ذلك في سوق الأسهم، أو حدث إطلاق منتج كبير، أو لعبة (رياضية إلكترونية أو فعلية)… اختر ما شئت.
ولكن في ثقافة النقاش الشبيهة بالدردشة هذه، تتفاوت جودة المنشورات تفاوتًا كبيرًا. من ناحية أخرى، تميل المنشورات بطبيعتها إلى الحدوث في نفس اللحظة تمامًا. لنفترض أن مباراة هوكي كبيرة جارية وأن شخصًا ما سجل هدفًا.
جزء كبير من المنشورات مجرد ردود فعل عاطفية، أو هتافات أو أنات:
“هدف!!! نعم يا ببي”
بعضها معلوماتي:
“سجل كروسبي، النتيجة 1-0 لصالح بينز”
قلة قليلة تتكبد عناء تقديم بعض التحليل:
“سجل كروسبي هدفًا في كسر التعادل، بعد جهد غير حذر من كابيتالز في الهجوم، لكنه بدا كثيرًا كأنه حالة تسلل. يجب على مدرب كابيتالز الاعتراض على هذا الهدف.”
الآن، بما أن منصة Discourse سريعة (شبه فورية)، فهذا يعني أنه حتى عندما تسير الأمور بسلاسة، ستحصل على عدة عشرات من المنشورات في اللحظة ذاتها تقريبًا. بالنسبة للقارئ، خاصة لمن لا يشاهد المباراة ويتابعها عبر موضوع الدردشة، فإن هذا يشكل تحديًا في تجربة المستخدم — فمن الصعب تمييز تلك المنشورات المعلوماتية وسط الهتافات والأنات. في غرف الدردشة الخاصة بمبارياتنا على المنتدى، نواجه غالبًا السؤال “ما هي النتيجة؟”، حيث ينسى المشاهدون للمباراة نشر المعلومة البديهية، أو تُفقد المعلومة وسط سيل الرسائل.
لا أعرف كيف يمكن أن يعمل هذا في الواقع، لكن سيكون من المثير للاختبار ما إذا كان بإمكان المشرفين تحديد إيقاع النقاش. على سبيل المثال، منشور واحد في الثانية. ستُوضع جميع المنشورات في قائمة انتظار، ولكن سيتم نشرها على الموقع بإيقاع محدد. إذا ولّد هدف 20 منشورًا تفاعليًا، فلن تظهر جميعها في الموضوع في نفس الوقت، بل خلال نافذة زمنية مدتها 20 ثانية. أليس من الأسهل متابعتها واكتشاف المعلومات ذات الصلة؟
بالطبع، قد يؤدي هذا إلى مشاكل أخرى؛ فإذا تجاوز إيقاع الرسائل الجديدة باستمرار إيقاع نشرها، فستتكون قائمة انتظار طويلة ومتزايدة، وستبدأ الدردشة في التخلف عن الواقع.
لست متأكدًا مما إذا كانت الفكرة واضحة، وحتى أنا لست متأكدًا من جودة الفكرة. الخلاصة هي أن تجربة المستخدم في الدردشة الفورية موضوع مثير للنقاش وقد يكون له إمكانات للمزيد من التطوير. أنا أدرك أن التركيز الأساسي لمنصة Discourse ليس إنشاء منصة دردشة — فهناك برمجيات أخرى لذلك. لكنها تحدث بطبيعتها.
أعجبني هذا الفكرة، لكنها ستحتاج إلى نوع من الحظر العكسي للظلال حتى يرى الناس منشوراتهم الخاصة فورًا. إذا لم يفعلوا ذلك، فقد ينشرون مرتين أو حتى ثلاث مرات، ظانين أن المنتدى لا يعمل.
وهو يضمن عدم تعطل الخادم إذا كان 1000 شخص يتصفحون موضوعًا واحدًا ويتم نشر مشاركات فيه.
أصبح العميل الآن يتصرف بشكل أنظف بكثير في هذه الحالات.
وتوقعًا لسؤال @ljpp هنا، ما زلت مترددًا بشأن الترحيح الخلفي، لأن هذا التغيير يُحدث تعديلات على واجهة برمجة التطبيقات (API) وهو تغيير كبير إلى حد ما. إذا قمنا بالترحيح الخلفي… فسيكون ذلك على الأرجح بعد بضعة أسابيع. أحتاج إلى مراقبة هذا في بيئة الإنتاج تحت الضغط، ونظرًا لأننا نواجه أحداثًا نادرة من هذا القبيل نظرًا للمرونة الكبيرة التي نتمتع بها في استضافتنا، فسيستغرق الأمر بعض الوقت لنتمكن من التقاطها.
أتفهم المنطق وراء عدم كون هذا مرشحًا للإرجاع إلى الإصدار السابق. لقد قمت بتعطيل محدد المعدل الخاص بنا، وغدًا هي المباراة التالية، لذا سنكون لدينا فكرة تقريبية عما إذا كان يعمل كحل عملي للم instances التي لا ترغب في الانتقال إلى النسخة التجريبية.
نحن بالتأكيد نخطط للانتقال إلى الفرع التجريبي خلال الأشهر القليلة القادمة. ومع ذلك، هناك بعض المخاوف الأخرى أيضًا - أشار @rizka إلى أن ترجمة اللغة الفارسية تتأخر (ولكنه قد يتمكن من العمل عليها في وقت لاحق من هذا الأسبوع).
أدى ذلك إلى تقليل عدد حالات التباطؤ الملحوظة بشكل كبير، لكنه لم يحل المشكلة. ارتفع حمل المعالج (CPU)، وتقلب حول 55% في أوقات الأحداث الرئيسية في اللعبة.
تم إجراء تغييرات حديثة للمساعدة في معالجة “التجمّدات”، حيث سيتوقف العميل مؤقتًا وينتظر إذا كان الخادم مثقلًا.
ومع ذلك، قد تكون الإجابة النهائية هي الحصول على خادم أكبر وتشغيل عدد أكبر من عمال Unicorn. راجع سكريبت discourse-setup للحصول على توصياتنا بشأن سعة الخادم إلى عدد العمال.
أشك في ذلك… المشكلة تحت حمل ردود مرتفع هي أنه قبل التصميم الجديد، كان بإمكاننا التسبب في فيضان يؤدي إلى تفعيل حدود المعدل بسبب max_reqs_per_ip_per_10_seconds وما شابه. ستحتاج إلى موارد هائلة للتعامل مع الحمل.
تأمل.
ينشر 30 مستخدمًا ردًا خلال 10 ثوانٍ.
100 شخص يطلعون على الموضوع.
يجب أن يكون الخادم قادرًا على معالجة 3000 طلب GET لطلب منشور واحد في كل مرة.
إذا فشل أي من هذه الطلبات لأي سبب، سيتجمد واجهة المستخدم ويبدو وكأنها معطلة.
يحل التصميم الجديد هذه المشكلة بشكل أنيق للغاية؛ حيث تتراجع العمليات بسلاسة، وتُجمَّع الطلبات إذا حدث تراكم، ولا يتجمد واجهة المستخدم، وما إلى ذلك.
لا أستطيع تخيل أن التصميم القديم قادر على التوسع ليدعم 100 مستخدم متزامن و30 ردًا خلال 10 ثوانٍ.
أرى أن التصميم الحالي المنقح يعمل بشكل ممتاز مع 1000 مستخدم متزامن يطلعون على موضوع يحتوي على 30 ردًا خلال 10 ثوانٍ.
.