واحد من الملفات /assets/application-7c87db9088046beb643be94b61428105469e084e8d02f141c57adfaf14168c63.js حجمه حوالي 3.1 ميجابايت ويسبب العديد من التحذيرات في ملف error.log لـ Nginx كوكيل عكسي.
تم تخزين استجابة الخادم الوسيط في ملف مؤقت /var/lib/nginx/proxy/2/77/0012036772 أثناء قراءة الخادم الوسيط، العميل: XXXXXX
هل يعرف أحد الغرض من هذا ملف جافا سكريبت الضخم؟
هل هناك طريقة لتقليل حجم هذا الملف؟ إحدى الطرق لتقليل التحذيرات في Nginx هي زيادة حجم المخزن المؤقت إلى 3.1 ميجابايت، لكن ألا يبدو ذلك كبيرًا جدًا مقارنة بالتهيئة الافتراضية لـ Nginx؟
عند تحميل موقع Discourse لأول مرة، يتم إرسال تطبيق JavaScript الكامل إلى المتصفح (يتم تخزينه مؤقتًا بعد ذلك، مما يجعل تحميل الصفحات اللاحقة أسرع بكثير). هذا هو الملف بحجم 3 ميجابايت.
من الجدير أيضًا التذكير بأن اتباع دليل التثبيت الرسمي يوفر لك وكيل عكس Nginx مُهيأ مسبقًا يقدم هذا الملف باستخدام ضغط Brotli الذي يقلل حجمه إلى 400 كيلوبايت.
ملف الإعدادات هذا هو القالب الذي نستخدمه في دليل التثبيت الرسمي، لكنه يُعدّل بشكل كبير بواسطة سكربت التثبيت أثناء عملية التثبيت أيضًا.
أخشى أننا نوفر ملف الإعدادات فقط عند اتباع دليل التثبيت الرسمي الخاص بنا. إذا انحرفت عن ذلك، فستحتاج إلى الحذر لتجنب فقدان كل ما ندعمه مثل brotli و HTTP/2 و IPv6 وما إلى ذلك.
@Falco من خلال قراءة منتدى Discourse، يمكن الشعور بأن استخدام حاوية منفصلة للويب وقاعدة البيانات هو المفضل أو ربما الطريقة الموصى بها. سيكون رائعًا إذا وُجد دليل رسمي حول إعداد nginx يدويًا أو الإعداد التلقائي للحاويات المنفصلة.
طريقتنا المفضلة للتثبيت هي تلك التي وثّقناها في دليل التثبيت الرسمي لدينا. مع ذلك، فإن استخدام حاوية ويب/بيانات منفصلة لا يؤثر على nginx المُعد مسبقًا داخل حاوية الويب، حيث يجب أن يعمل بنفس الطريقة دون الحاجة إلى وكيل عكسي إضافي.
البحث عن تحسين الأداء عند استضافة منتديات Discourse متعددة باستخدام: وكيل Nginx → حاويات منفصلة للويب وقاعدة البيانات. في هذا السيناريو، أفترض أن تحسينات الأداء التي يقوم بها التثبيت الرسمي يجب تنفيذها يدويًا في وكيل Nginx.