لقد وصلنا للتو إلى ذروة حركة المرور بحوالي 1,500 مستخدم متزامن (معظمهم مجهولون) يزورون صفحة واحدة.
وعندها دخل المنتدى في الوضع الذي يتم فيه عرض تحذير لجميع الأعضاء بشأن الحمل المرتفع.
خادم Digital Ocean محسّن لمعالجة المعالجات (CPU-Optimized Droplet)
معالج مخصص: 4 vCPUs
الذاكرة العشوائية (RAM): 8 جيجابايت
عمال Unicorn: 10
بما أن حوالي 50% فقط من الذاكرة العشوائية (RAM) والمعالج (CPU) مستخدمين، فهل سيكون من المفيد زيادة عدد عمال Unicorn لحالات ذروة حركة المرور هذه من الزوار المجهولين أم لا؟
نعم، زيادة عدد الشركات الناشئة ذات التقييم المرتفع هو الخطوة الأولى هنا.
لقد قمت بزيادة عدد العمال إلى 24. لا يوجد فرق (يظهر لا يزال “بسبب الحمل الشديد، يتم عرض هذا مؤقتًا للجميع كما سيراه المستخدم غير المسجّل”), مع ذروة مماثلة في الزوار المتزامنين (99% مجهولين) الآن:
أعلم أن @sam قد قضى وقتًا طويلاً في هذا مؤخرًا، وربما يكون لديه تعليق؟
@sam هل لديك أي أفكار حول كيفية تحسين الأداء بشكل أكبر لحركة المرور القصوى من المستخدمين المجهولين (على سبيل المثال، إذا أصبح موضوع واحد viral على وسائل التواصل الاجتماعي). في كلتا الحالتين المذكورتين أعلاه، لا يزال هناك مساحة كافية في الذاكرة ووحدة المعالجة المركزية (وفقًا لـ Digital Ocean)، ولم نصل حتى إلى حمل قدره 4، ومع ذلك، يدخل المنتدى في وضع “الحمل الشديد”، على الرغم من مضاعفة عدد العمال ثلاث مرات.
دخلت مرة أخرى في “وضع التحميل الشديد”، مع وجود 600 زائر متزامن فقط (99% منهم مجهولون)، وحمل لا يتجاوز 1.
تحتاج إلى جمع بعض البيانات حتى نعرف ما هو الاختناق.
أعتقد أن مراقب بيانات DO ليس حساسًا بما يكفي وهو مضلل إلى حد ما. لقد قمت بتجربة حمل شديد مع Hetzner و Digital Ocean. مع Hetzner، عندما ظهرت رسالة الحمل الشديد، كان هناك ارتفاع حاد وقصير وصل إلى 120%.
استمر ذلك ربما ثانية واحدة قبل أن ينخفض إلى نطاق 40-50%.
أعدت إنشاء نفس الموقف مع Digital Ocean، وحسب ذاكرتي، بدا أن استخدام المعالج لم يتجاوز 50% أبدًا. (لكن لا يمكنك تغيير محور السينات إلى مستوى الثواني)
تخميني هو أن مستوى المعالج في DO قد يكون متوسطًا لـ 5 أو 15 ثانية. لذا لا ترى هذه القمم الحادة والقصيرة.
سنحتاج إلى تقارير من مُصدّر Prometheus للتحقق بشكل أعمق.
إذا كان لديك ذاكرة عشوائية (RAM) ومعالج (CPU) كافيان، فيمكنك دائمًا إضافة المزيد من عمال Unicorn، مما سيمكنك من التوسع لمواجهة هذه الذروات. فقط تجنب استخدام ذاكرة التبديل (Swap) لأن ذلك سيؤدي إلى انخفاض كبير في الأداء.
يبدو أنه في مثل هذه الحالة، يجب أن تكون صفحة الموضوع الواحد قادرة على التخزين المؤقت وتقديمها بشكل ثابت لفترة قصيرة دون الحاجة للوصول إلى الخلفية على الإطلاق. ليس لدي أي فكرة عما إذا كان Discourse قادرًا على ذلك (أي ضبط رؤوس التحكم في التخزين المؤقت عند التحميل وتقديم المحتوى للمستخدمين المجهولين) وما إذا كان إعداد DO يحتوي على وكيل تخزين مؤقت قادر في السلسلة، لكنها فكرة تطويرية قد تستحق التفكير فيها إذا لم أكن مخطئًا تمامًا ولم يتم تنفيذها بالفعل.
ربما فكر @sam أو فعل ذلك بالفعل، أو يعرف لماذا قد تكون فكرة سيئة!
يحدث ذلك بالفعل بشكل ديناميكي تحت حمل مقاس على أساس كل موضوع، وهذا بالضبط ما يشير إليه
.. هو. ومع ذلك، فهو للقراءة فقط، لذا لا يمكن للأشخاص إجراء محادثات فعلية في هذا الوضع.
نعم، لكن اقتراحي هو توجيه مستخدمين مجهولين فقط إلى صفحة مخزنة مؤقتًا مع مهلة زمنية قصيرة (60 ثانية؟) لتخفيف العبء عنهم، على أمل أن يستمر باقي الموقع في العمل بوضع القراءة والكتابة.
سيكون ذلك رائعًا. حاليًا، إذا قمنا بتسليط الضوء على موضوع في قناة تيليجرام الخاصة بنا التي تضم أكثر من 200,000 مشترك، فإن ذلك يضع موقع Discourse بالكامل في وضع “للقراءة فقط” لمدة ساعة تقريبًا. على الرغم من أن عدد المستخدمين المسجلين يبلغ حوالي 50 فقط (99% من الزيارات من مستخدمين مجهولين).
هذا يحدث بالفعل، لدينا ذاكرة تخزين مؤقت قوية مباشرة في Redis للمستخدمين المجهولين في صفحات قائمة المواضيع وصفحات المواضيع. مهلة زمنية مقدارها 60 ثانية.
سأحاول تشغيل Prometheus لاكتشاف الاختناق، ولكن على الأرجح أن المشكلة تكمن في مراقبة DigitalOcean التي تتأخر كما ذكر @Alec. إذا كان الأمر كذلك، فأنا أفترض أن الحل هو الانتقال إلى جهاز أكبر؟
