من خلال خبرتي، لا يحل أي نهج حالي هذه المشكلة مباشرةً، ولا يوجد لها حل خطي. في الواقع، فصلها على آلات مختلفة ليس حلاً فوريًا لتلك المشكلة.
نحن أيضًا نواجه انخفاضات حادة ورسائل مثل “الموقع مشغول للغاية، لذا تظهر لك وكأنك غير مسجل” عند حدوث حدث كبير (مثل لعبة، كما ذكر @ljpp)، مما يؤدي إلى إبطاء الموقع بأكمله، وليس فقط الأشخاص داخل ذلك الموضوع.
لذلك، جربت شيئين مختلفين: إعداد منفصل و"آلة كبيرة"، وكلاهما يعاني من هذا النوع من المشكلات. يتم مراقبة مثيلاتي باستخدام Prometheus، وتكون السجلات مرئية على Grafana وما إلى ذلك، لذا لدي تحكم دقيق جدًا في أداء الأجهزة/الحاويات، ويمكنني تأكيد أنه بغض النظر عن ما تفعله، ستحدث المشكلة على أي حال.
إذا وضعت آلة كبيرة خلفها، فقد تؤخر المشكلة قليلاً، لكنك ستواجه الأخطاء وانقطاعات الجلسات، وستكون الآلة شبه خاملة من حيث استخدام القرص أو المعالج أو الذاكرة. وهذا يحدث في كل من “التثبيت الافتراضي” و"تثبيت الحاويتين".
مع آلات مختلفة، تظل المشكلة نفسها، بغض النظر عما إذا كانت الآلات من نفس النوع أو أن إحداهما “مُحسّنة للمعالج” والأخرى “مُحسّنة للقرص” وما إلى ذلك. إلى ذلك، يجب إضافة طبقة إضافية محتملة لفشل الاتصال بين آلتين مختلفتين، مما سيؤدي حتمًا إلى تأخير، على الرغم من أن مقدار هذا التأخير قد يختلف حسب كيفية إعدادك لذلك الاتصال و"مدى بعد" الآلتين عن بعضهما البعض، لكنك ستلاحظ نفس السلوك.
كملاحظة، يحدث هذا النوع من السلوك أيضًا مع أشياء مثل إضافة Babel، لكن يبدو لي أن إضافة Babel يمكنها التعامل مع عدد أكبر بكثير من عمليات الكتابة “المتزامنة”، حتى لو كانت “الرسائل الفورية” في الواقع مواضيع مخفية، لكن الفرق يكمن في كيفية عرضها و"تحديثها"/“جلبها”. هذا الاختلاف في السلوك قادني إلى الاستنتاج بأن هذا شيء يتعلق بتطبيق معين ينشأ من مشكلة من نوع الواجهة الأمامية “تسبب في انهيار” التطبيق (بما أن الواجهة الأمامية ليست مجال تخصصي، على عكس الواجهة الخلفية) والعمليات الجارية عند النشر وبقاء الأشخاص على موضوع ينتظرون “تحديثه ذاتيًا” بعشرات الرسائل في دقيقة واحدة.
إلى ذلك، يجب إضافة العامل البشري: عندما يشعر الناس بأن الموقع “بطيء” أو أن موضوعًا ما “لا يتحدّث بالسرعة التي ينبغي له بها”، سيقومون بالتحديث (F5) بشكل مفرط، مما يضيف حمولة إضافية. لكن حظًا موفقًا في “التثقيف” في هذا الصدد 