لدي تثبيت جديد لـ Ubuntu 20 و Docker و Discourse. لم أضف أي إضافات ولدي مستخدمان فقط في قاعدة البيانات الخاصة بي، ومع ذلك تستغرق عمليات البناء أكثر من 40 دقيقة لإكمالها! لا يوجد جزء معين من عملية البناء بطيء، فالأمر برمته يستغرق وقتاً طويلاً جداً لإكماله. إنه خادم بمواصفات جيدة جداً، ولدي خادم آخر يخدم 20 موقعاً لعملائي بنجاح، لذا فهي ليست مشكلة في الأداء.
يتوقف هنا لمدة 4 دقائق على الأقل:
warning Resolution field "lodash@4.17.21" is incompatible with requested version "lodash@4.17.15"
يتوقف مرة أخرى هنا فوراً بعد ذلك لمدة 4-5 دقائق أخرى:
warning " > @mixer/parallel-prettier@2.0.1" has unmet peer dependency "prettier@^2.0.0".
لقد حاولت البناء باستخدام --skip-prereqs دون جدوى، ولا يزال الأمر يستغرق 40+ دقيقة في كل إعادة بناء.
شكراً للتأكيد @Falco، لدي 1GB من ذاكرة الوصول العشوائي (RAM) (قليلة ولكن لم أحتج المزيد لموقع خفيف). يستغرق البناء أكثر من 30 دقيقة (عادة ما يكون حوالي 10 دقائق).
رافائيل، هل هذا تراجع على 2.9.0 بيتا أم 2.8.0 مستقر؟
بالعودة إلى المنشور الأول، هل يعرف أحد من أين يأتي هذا التحذير؟
لا أعرف ما إذا كان هذا شيئًا يستحق النظر فيه حقًا، ولكن شخصيًا، لاحظت في العديد من الأشياء انخفاضًا في الأداء عند استخدام Ubuntu 20.04 (Discourse، خوادم الويب، خوادم الألعاب) حتى عند محاولة طرق مختلفة للتحسين
في الوقت الحالي، أقوم بتشغيل Discourse في Droplet للاختبار بنفس الخصائص، ويستغرق إعادة البناء حوالي 8-12 دقيقة (Ubuntu 18)
لا أعتقد أن البناء “يعلق” عند تلك التحذيرات. إنه يبني بصمت ويتم إخراج التحذيرات كجزء من العملية.
أي أن التحذيرات أو مشكلتها الأساسية لا تساهم في وقت البناء الطويل.
هذا تغيير ضخم نعمل عليه منذ سنوات، وهو يدخل المراحل النهائية. خلال هذه الفترة، لدينا فترة “ستزداد الأمور سوءًا قبل أن تتحسن”، وهذا أحد الآثار الجانبية “السيئة” لذلك.
هناك أيضًا احتمال للسماح للأشخاص الذين لديهم وحدات معالجة مركزية بطيئة بالانسحاب من خرائط المصدر والميزات “الجميلة” الأخرى لتسريع عمليات إعادة البناء الخاصة بهم.
نقدر التحديث @Falco على وحدة معالجة مركزية رباعية مع 8 جيجابايت من ذاكرة الوصول العشوائي على Linode وعادةً ما يكون هذا إعدادًا رائعًا، ولكنه كابوس الآن. لدينا عدد من التغييرات التي كنا نخطط لإجرائها، ولكن سيتعين علينا الانتظار الآن حتى تعود سرعات النشر إلى طبيعتها تقريبًا.
@Falco ألاحظ أيضًا أنه خلال الإصدارات القليلة الماضية يتدهور أداء الخادم، ويستغرق تحميل المواقع وقتًا أطول ويستهلك المزيد من الذاكرة. لم تحدث أي تغييرات في إعداداتي خلال العامين الماضيين (الإضافات، الأجهزة، إلخ) وعدد المستخدمين النشطين على الموقع هو نفسه أيضًا. هل هناك طريقة لمراقبة أداء الموقع بشكل موضوعي من داخل Discourse يمكننا بعد ذلك الإبلاغ عنه هنا. في الوقت الحالي، الطريقة الوحيدة التي أعرفها هي عندما أفتح الموقع يستغرق تحميله لأول مرة أكثر من 8 ثوانٍ (مع الإصدارات السابقة كان دائمًا أقل من 2-3 ثوانٍ).
ما هي أوقات إعادة البناء التي ترونها؟ لقد احتجت للتو إلى إعادة البناء بسبب تغيير في SMTP، واستغرقت أقل من 12 دقيقة لموقع صغير جدًا (30 مستخدمًا، 400 منشور).
هذا الموضوع يدور حول “أوقات البناء” وليس حول أوقات تحميل الصفحات. إذا كنت تتحدث عن تدهور أوقات استجابة الصفحات، فيرجى فتح موضوع جديد حول ذلك مع بعض البيانات.
أعتقد أنني اكتشفت سبب استغراق تحميل الصفحات وقتًا طويلاً. تم تعيين حجم قاعدة البيانات المشتركة في app.yml ليكون مساويًا للذاكرة الإجمالية للنظام. أعدته إلى القيمة الافتراضية (25٪)، وأعدت البناء، وأصبح الآن أقل من ثانية.
شكراً على التحديث 
على وحدة معالجة مركزية رباعية مع 8 جيجابايت من ذاكرة الوصول العشوائي على Linode وعادةً ما يكون هذا إعدادًا رائعًا، ولكنه كابوس الآن. لدينا عدد من التغييرات التي كنا نخطط لإجرائها، ولكن سيتعين علينا الانتظار الآن حتى تعود سرعات النشر إلى طبيعتها تقريبًا.