لقد فكرت في محاولة تقليل استهلاك الذاكرة لعمليات Unicorn من خلال تكوين خادم nginx الخارجي (الذي أملكه بالفعل لعرض صفحة الصيانة 502 ولتعيين عناوين IPv6 بشكل صحيح) لخدمة طلبات الصور أيضًا؛ بهدف الحصول على الكثير من الفوائد الناتجة عن نقل الصور إلى S3 (أو خدمة كائنات متوافقة) مع الحفاظ على الموقع متمركزًا على خادمي. (هذا لن ينقل أصول الموقع الأخرى بعيدًا عن عمليات Unicorn، لكن هذه الأصول مخزنة بشكل جيد من صفحة إلى أخرى، لذا فإن التكلفة الإجمالية على عمليات Unicorn أقل بكثير.)
تمامًا كما يتم توجيه خادم nginx الخارجي إلى منفذ في /var/discourse/shared، سأقوم بخدمة /uploads من /var/discourse/shared/$container/uploads.
لم أرَ ذكرًا هنا في meta بأن أي شخص قد فعل ذلك، رغم أن مهارتي في البحث قد تكون ضعيفة. هل هناك أي أسباب أغفلتها تجعل هذا الإجراء غير فعال أو يعمل بشكل سيء عمليًا؟
أعتقد أن تمكين التخزين المؤقت على nginx الخارجي سيحقق نفس الفائدة فيما يتعلق بتحميل unicorns، دون الحاجة إلى إعداد شبكة توصيل المحتوى (CDN). أرى رؤوس تحكم في التخزين المؤقت على جميع أصول JavaScript، لذا قد أجرب هذا…
… حسنًا، أرى أن nginx الداخلي يستخدم بالفعل proxy_cache مع صلاحية 7 أيام للطلبات غير الخاطئة:
location ~ ^/(svg-sprite/|letter_avatar/|letter_avatar_proxy/|user_avatar|highlight-js|stylesheets|theme-javascripts|favicon/proxied|service-worker) {
...
# ملاحظة: لا يمكن استخدام x-accel-redirect مع proxy_cache
proxy_cache one;
proxy_cache_key "$scheme,$host,$request_uri";
proxy_cache_valid 200 301 302 7d;
proxy_cache_valid any 1m;
proxy_pass http://discourse;
break;
}
كيف تساعد شبكة توصيل المحتوى (CDN) في حالة unicorns في هذه الحالة؟ أرى stylesheets في هذه القائمة.
