لدينا 5 ملايين منشور، والبحث سريع جدًا. الاستضافة على 6 أنوية مشتركة من معالج Xeon E5-2680 بسرعة 2.8 جيجاهرتز مع 16 جيجابايت من ذاكرة الوصول العشوائي وتخزين SSD. مع ذلك، لا أملك مقاييس حول عدد المنشورات المتزامنة التي يبدأها مستخدمونا، وقد تكون هناك مشاكل في القفل.
أما النشر، فمن ناحية أخرى، غالبًا ما يكون بطيئًا جدًا. قد يستغرق الأمر من 6 إلى 7 ثوانٍ حتى يتم إرسال المنشور. ومع ذلك، فإن نظام Discourse غير مُعيق أثناء معالجته، لذا لا يؤثر ذلك سلبًا على تجربة المستخدم.
هذا… ليس طبيعيًا.
أعتقد أن هذا هو الأرجح في أي موضوع يحتوي على مئات أو آلاف المشاركات. أما في المواضيع القصيرة، فلا ينبغي أن يكون الأمر كذلك.
أتذكر أن منتدى @Wingtip يحتوي على عدد هائل من المواضيع الطويلة جداً.
نعم، بالتأكيد نفعل ذلك.
هل أوقات النشر البالغة 6-7 ثوانٍ خاصة بالمواضيع الضخمة؟ إذا قمت بالرد على موضوع يحتوي على 100 رد، هل يستغرق الأمر أيضًا 6-7 ثوانٍ؟
لم أتمكن من إعادة التكرار للتو — النشر البطيء متقطع. لا يبدو أنه يرتبط بعدد المنشورات في الموضوع. ربما تكون هناك مشكلة في القفل مع شخص آخر ينشر في نفس الوقت أو شيء من هذا القبيل.
7 منشورات = سريع جدًا، تقريبًا مثل ما هنا في الميتا
500 منشور = ربما أبطأ قليلاً، ليس سيئًا جدًا. ربما 1.5 ثانية؟
16 ألف منشور = يبدو تقريبًا مثل 500
وأعتقد أن الأداء يتأثر أيضًا إذا كان عدد كبير من الأشخاص يصلون إلى موضوع ضخم، مما يبطئ خادم PG بالكامل بسبب الطلبات الموضوعة في طابور.
هذا منطقي، فالأولوية لتجربة الكثير من الأشخاص الذين يشاهدون موضوعًا ما، بدلاً من شخص واحد أو اثنين يحاولان النشر.
إلى أي مدى تشعر بالشجاعة؟ هل تمانع في تمكين mini_profiler لفترة؟ سيوفر لك ذلك توقيتات على الجانب، ثم يمكننا عزل الاستعلام الذي يسبب المشكلة بالنسبة لك!
استغرق منشوري هنا 576 مللي ثانية
الاستعلام الأسوأ هو:
ويعمل @riking على طلب سحب (PR) سيصلح هذه المشكلة 
ما مدى تأثير تفعيله على الأداء العام؟ وهل يمكن تفعيله دون إعادة بناء الموقع؟ لم أتمكن من نجاح إعادة البناء منذ تغيير PostgreSQL 12، حتى مع إبقائه على الإصدار 10.
يجب عليك تعيين عنوان بريدك الإلكتروني كبريد مطور في ملف app.yml. يمكنك تطبيق التغيير دون إعادة البناء عن طريق تدمير وإعادة تشغيل الحاوية. إذا قمت بإجراء تغييرات على الحاوية عبر ترقية discourse docker، فستفقد هذه التغييرات.
يمكنك أيضًا تعديل ملف config/discourse.conf داخل الحاوية ثم تشغيل الأمر التالي:
sv restart unicorn
بما أن عمليات إعادة البناء تفشل، فإن قلقي هو أنه إذا قمت بتدمير الحاوية، فسأكون في مأزق تام. لقد واجهت العديد من الأخطاء أثناء محاولة ترقية PostgreSQL 12 أمس، لذا لا أشعر بالراحة لتغيير أي شيء حتى أكون واثقًا من أنني لن أتسبب في توقف الموقع لفترة طويلة.
حسنًا، النصيحة المجانية تساوي ما تدفعه مقابلها، لكن من الآمن نسبيًا تنفيذ ما يلي:
cd /var/discourse
./launcher enter app
vi config/discourse.conf
# في محرر vi، عدّل سطر developer_emails لتضمين عنوان بريدك الإلكتروني ثم غادر vi
sv unicorn restart
# ابدأ في القلق لمدة 30-90 ثانية حتى يعاد تشغيل خادم الويب ويبدأ في عرض الصفحات
ومع ذلك، لا يزال بإمكانك إتلاف الأشياء بهذه الطريقة. أعتقد أنه من الممكن إفساد ملف الإعدادات بحيث لا يتمكن discourse من البدء.
نجح الأمر sv restart unicorn، بينما فشل الأمر sv unicorn restart.
أحيانًا أخطئ في ذلك بنسبة ثلث الوقت تقريبًا. 
لكن هذا تحسن، حيث كنت أخطئ في نصف الوقت سابقًا.
هل هذا ما كنت بحاجة إليه؟ هذا منشور في موضوع يحتوي على 16 ألف منشور. بدا وقت النشر طبيعيًا، وليس بطيئًا بشكل خاص.
إليك المخرجات الكاملة:
https://paste.mozilla.org/f5nJrPag
استعلام مدته ثانيتان قادم من ملف app/models/user_stat.rb:159:in `update_topic_reply_count’.
إذًا، إنه نفس الأمر الذي يعمل عليه @riking.
عظيم! أي تحسينات جوهرية في وقت النشر ستجعل مستخدمينا سعداء حقًا، فهذا هو الأمر الأكثر شكاوى عليه حاليًا. على الرغم من أنني لا أشك في أنهم سيجدون شيئًا آخر للشكوى منه بعد فترة وجيزة.
إذا كان هذا يجعلك تشعر بالتحسن قليلاً، فقد اشتكيت أنا أيضًا من هذا الاستعلام، لأن لدي حالة قراءة كثيرة هنا في الميتا. نحن نعمل دون جدوى لحساب الأشياء في كل رد…
في استيراد الاختبار لدينا من برنامج آخر، لدينا موضوع يحتوي على ما يزيد قليلاً عن 200,000 منشور، وتمكّنت من النشر فيه دون أي مشكلة. يجب أن يكون السبب هو أن حجم الموضوع ليس هو ما يهم، بل المستخدم الذي يقوم بالنشر.
