مع هذه الإعدادات، كانت تجربة المستخدم أفضل. نعم، كانت هناك عدة “اختناقات” وسُجّل عدد كبير من أخطاء 429 في مفتش كروم الخاص بي. كان حمل المعالج منخفضًا. لكن من ناحية أخرى، كانت اللعبة المنزلية هادئة نسبيًا (كان العديد من الأعضاء النشطين موجودين في الموقع، ولم يكونوا يتحدثون في الدردشة).
لا يمكنني تحديد الإعدادات التي يجب تعديلها، ولكن بناءً على تجربتي الشخصية نسبيًا:
لا يزال ميزات الكود تحمي الخادم بشكل مفرط من حيث الحمل. ربما يمكن السماح بمستوى إجهاد أعلى قليلاً على الخادم.
عندما يتراجع العميل، فإن التأخير طويل جدًا من منظور تجربة المستخدم. تستمر اللعبة ويمكن أن يحدث الكثير خلال دقيقة. تتعطل الدردشة، حيث يشير الأشخاص إلى أحداث مختلفة في اللعبة. (هذا يفاقم مشكلة التأخيرات الزمنية المختلفة بين الوقت الفعلي والتلفزيون الكابلي وIPTV ومخزن Chromecast لمدة 20 ثانية، وما إلى ذلك.)
يرى المستخدم فقط أن الدردشة قد توقفت، لكنه لا يتلقى أي مؤشر على أن الموقع لا يزال متصلًا ونشطًا. ومن المرجح أن يقوم بتحديث الصفحة أو القيام بأشياء أخرى، مما يضيف إلى الحمل المرتفع.
فقط لاستبعاد بعض الاحتمالات، قمت بترقية الخادم إلى 8 أنوية افتراضية و32 جيجابايت من ذاكرة الوصول العشوائي. قمت بضبط مخازن قاعدة البيانات على 16 جيجابايت وعدد عمليات أوركسترا (Unicorns) على 16. عادت التعديلات الأخرى إلى الإعدادات الافتراضية.
لسوء الحظ، لم يحقق الترقية سوى القليل. تتجمد المناقشات السريعة باستمرار، حتى مع نشاط متوسط.
الأداء بائس في الوقت الحالي. أظن أنني بحاجة إلى البدء في النظر إلى Prometheus وما شابه. أنا متأكد بنسبة 95% من أن أداء البرنامج تراجع بشكل خطير منذ الإصدار v2.3.
كان تعليق الأخ @Iceman مهملاً إلى حد كبير في سبتمبر. فهو يبلغ عن حدوث الاختناقات بغض النظر عن العتاد الذي يستخدمه؟
أنا أشك في أنك تواجه عنق زجاجة في Redis، ولكن كما قلت مرارًا وتكرارًا، لا يمكننا التأكد إلا إذا جمعت تلك الإحصائيات. بدونه، قد نلجأ إلى علم التنجيم.
إذا كانت شكوكي صحيحة، فسوف يفسر ذلك أيضًا أن إضافة المزيد من الأنوية البطيئة والذاكرة العشوائية (RAM) للمشكلة لا يُحدث فرقًا، نظرًا لأن Redis يعمل بخيط واحد، فلا يمكنك التوسع إلا من خلال الحصول على أنوية عالية الأداء.
سنطلق صورة جديدة مع الإصدار النهائي من 2.6 بحلول نهاية الشهر، وستأتي مع Redis 6 ومتغيرات جديدة في app.yml لاستخدامها على النحو الأمثل. أخبرني إذا كنت ترغب في تجربتها مبكرًا، ويمكنني تزويدك بالتعليمات اللازمة لذلك.
مرة أخرى، لا يوجد عملاء يبلغون عن هذا السلوك (من بين الآلاف، والكثير منهم أكثر ازدحامًا من موقعك)، لذا فإن أي مناقشة إضافية في هذه المرحلة عديمة الفائدة إلى حد كبير — فليس لدينا أي رؤية حول أي حالة إعداد غريبة أو مشاكل غريبة في أداء الأجهزة قد تكون لديك هناك.
نأمل في المستقبل أن يتغير هذا الأمر وأن نحصل على رؤية أفضل للمشكلة الفعلية.
إذًا، إذا كان ريدز (Redis) هو الاختناق، فكيف يمكنك التوسع أفقيًا؟
ما زال يُحيرني ما الذي تغير منذ الموسم الماضي. لا أرى نموًا عضويًا كبيرًا، ولا زيادة في شعبية دردشة اللعبة. ومع ذلك، فإن قدرتنا على الخدمة قد انخفضت بشكل كبير، وهي تعاني حتى في أكثر الألعاب هدوءًا.
إلى أن تتمكن من جمع مقاييس من مثيل Discourse التاريخي الخاص بك، ثم تقارنها بالمقاييس التي تجمعها من التثبيت الحالي، مع الحفاظ على نفس الأجهزة تمامًا، سيبقى هذا لغزًا.
قد يكون الفرق كله هو أن مقدم خدمة VPS الخاص بك نقلك من جهاز فيزيائي إلى آخر، أو أن لديك جارًا صاخبًا، أو أن خادم VPS الخاص بك يشغّل الآن 17 خدمة مشتركة في المتوسط مقابل 13 خدمة لكل جهاز.
يرجى عدم التكهن بمحاولة دفع المشكلة إلى مزود خدمة الخوادم الافتراضية (VPS). تعتبر UpCloud واحدة من أفضل المزودين في السوق، وقد تحقّقوا من جانبهم للتأكد من عدم وجود أي شيء غير عادي. إنهم يعلّقون إعلاناتهم على موقعنا، ومن غير الجيد سمعة الموقع أن يعاني من تباطؤ
لكن لا توجد بيانات تاريخية، وبصراحة، لم أكن أركز بشكل كبير لأن كل شيء كان يعمل بسلاسة، حتى بدأت أولى مباريات العرض في أغسطس. بالطبع، تغيرت السلوكيات البشرية بفضل جائحة كوفيد، ومن يدري ما غير ذلك. لكنني لا أستطيع رؤية ذلك في مقاييس موقعنا أو خادمنا.
ومع ذلك، فهذا يمثل مادة اختبار ممتازة. لقد زوّدنا @riking ببعض لقطات الشاشة لما يحدث عندما يبدأ الحمل الزائد على الخادم. أظن أنكم لا تشاهدون ذلك في كثير من الأحيان.
لاحظ أن لا أحد يختلف معك — نحن فقط نوضح أن الطبيب لا يستطيع سوى قدر محدود من تشخيص المريض عندما يكون مقيدًا بمشاهدة المريض عبر كاميرا فيديو على الإنترنت.
أردت فقط القول إن هذا كان تمامًا كما عشته عندما قمت بإعداد موقعي لأول مرة (لذا فهو ليس فريدًا لموقعك).
إليك موضوعًا أنشأته حول ذلك في ذلك الوقت:
هذا هو ما دفعني للانتقال إلى خيارات معالج الذاكرة المختلفة الموضحة هنا:
للأسف، لم أتمكن حتى الآن من التبديل بشكل صحيح إلى Hetzner من Digital Ocean كما وصفت (بدأت وظيفة جديدة). لكنني سأفعل ذلك بمجرد أن أجد فرصة هذا الشهر.
تجربة المستخدم النهائي المتمثلة في طرده من الموضوع، أو بقائه في الموضوع (مع رسالة تسجيل الخروج). بدا أن ذلك يعتمد على الحمل. (تم توجيه عدد أكبر من المستخدمين إلى فهرس الموقع بعد تسجيل هدف)
لا أملك معرفة تقنية كافية لأكون مفيدًا، لكنني شعرت أنه قد يكون من المفيد معرفة أن موقعًا رياضيًا مع قمم مشابهة لسلوك الدردشة يؤدي إلى مشكلة مماثلة. لكن مشكلتي (موقع أصغر حجمًا وأحدث) تم حلها من خلال ترقية الخادم بشكل أكبر.
تم تثبيت بيئة جديدة مكونة من حاويتين على خادمين افتراضيين (web_only و data).
وبشكل مفاجئ (بالنسبة لي)، فإن خادم web_only يعاني من استهلاك الموارد بالكامل، بينما يكون خادم data محمّلاً بشكل خفيف نسبياً. كلاهما يعملان بخطة UpCloud.com التي توفر 4 أنوية افتراضية و 8 جيجابايت من ذاكرة الوصول العشوائي.
تم ترقية خادم web_only إلى خطة UpCloud.com التي توفر 6 أنوية افتراضية و 16 جيجابايت من ذاكرة الوصول العشوائي. وتم زيادة عدد وحدات يونيكورن إلى 18.
رغم ذلك، ما زلنا نواجه حدوداً مختلفة من نوع 429. ومع ذلك، لم يتم تفعيل وضع “النظام تحت حمل مرتفع”.
تم إفساد موسم الهوكي بسبب جائحة كوفيد، والآن يلعبون بضع مباريات عشوائية دون جمهور. نظرًا لأن لدينا أرصدة استضافة مع UpCloud.com، فإننا نعمل على تحسين التجربة باستخدام ما لدينا. الآن نستخدم 6 أنوية افتراضية وذاكرة 16 جيجابايت لـ web_only، و4 أنوية افتراضية وذاكرة 8 جيجابايت لـ data، مع تشغيل unicorns عند 18.
قمنا مرة أخرى بتعطيل مُحدِّد معدل الطلبات…
DISCOURSE_MAX_REQS_PER_IP_MODE: none
…مما يساعد، لكننا لا نزال نتلقى أخطاء 429 من استعلامات POLL، والتي تُسبب تأخيرًا طويلًا/تجميدًا للمستخدم النهائي. سنواصل التعديل عن طريق زيادة DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS.
ربما يكون الأمر كذلك، لكننا نود أن نكون أقل حماية قليلاً تجاه الخادم، لأن طفرات النشاط الطبيعية قصيرة جدًا وتستقر عمومًا خلال دقيقة أو نحو ذلك. لذا فإن رفع العتبات قليلاً قد يحسن تجربة المستخدم، مع انتظار الانتقال.
كانت الألعاب شحيحة (بفضل كوفيد)، لذا لم تكن لدينا سوى فرص قليلة لقياس هذا الأمر وتعديله.
ما اكتشفناه هو أنه حتى مع مواردنا المحسّنة من العتاد (6+4 أنوية افتراضية و16+8 جيجابايت من ذاكرة الوصول العشوائي)، فإن جمهورًا نشطًا بشكل متواضع قادر على التسبب في 429 حالة تجمّد للعميل. رأينا ذلك في مباريات كأس العالم U20، التي جذبت حوالي 50% من جمهورنا المعتاد للألعاب في غرف الدردشة.
من خلال القياس والتجربة والخطأ، اعتمدنا التعديلات التالية:
يبدو أن هذا يلغي 80% من حالات الخطأ 429، مما يتيح تجربة سلسة نسبيًا لجزء كبير من المستخدمين.
كانت الخطوة التالية هي شراء أنواع مختلفة من موارد العتاد، إما باستخدام أجهزة مخصصة لسرعة الخيط الواحد أو التحول إلى مزود خدمة VPS يقدم خططًا بعدد هائل من الأنوية الافتراضية. أما بالنسبة لنا، فإن الخطوة التالية هي العمل مع فريق استضافة Discourse، كما أشار سام سابقًا.
نأمل أن تكون هذه التعديلات مفيدة لـ @iceman و @alec أو أي شخص آخر. تأكد من مراقبة استخدام وحدة المعالجة المركزية وطابور الانتظار. كما أن ما تعلمته من هذه التجربة هو أن حاويتين أفضل بشكل كبير من حاوية واحدة - حيث يمكن تطبيق التعديلات مع توقف شبه معدوم، واستغلال موارد العتاد بشكل أكثر دقة.
ما زلت مهتمًا بأي تعديلات أو اكتشافات جديدة قد تساعد في تحسين الأداء وتجربة المستخدم في المناقشات السريعة التي تدفعها الأحداث الواقعية.
