مرحبًا! أنا مسؤول في https://discuss.pixls.us، وهي مجتمع للمصورين الذين يستخدمون البرمجيات الحرة. نحن محظوظون بما يكفي لتغطية تكاليفنا من خلال تبرعات المجتمع، لكنني لست متأكدًا من مدى استدامة ذلك مع استمرار نمونا. كما أنني أتعامل بجدية مع مهمة إنفاق تبرعات الناس، وقد كنت أحاول التفكير في طرق لتقليل تكاليفنا.
بما أننا صانعو صور، فإن منتدانا غني جدًا بالصور. تكلفتنا الأكبر على الإطلاق هي تكاليف عرض النطاق الترددي على Amazon S3 (وهي تكاليف عرض النطاق الترددي الصادر بشكل شبه كامل). أما تكاليف التخزين على S3 فهي ضئيلة للغاية.
سيكون من المفيد استخدام webtorrent لتحميل هذه الصور ووسائط أخرى، على غرار Peertube.
أرى هذه الميزة على أنها أمران: (1) يقوم المستخدمون الذين يزورون الموقع بتحميل الوسائط من مستخدمين آخرين باستخدام webtorrent، و(2) نوع من تغذية RSS يمكنني الاشتراك فيها في عميل تورنت بحيث يتمكن المستخدمون من أن يكونوا “مُوزِّعين فائقين” (super seeders) يقدمون للموقع عرض النطاق الترددي فقط.
يجب عليك حقًا استخدام شبكة توصيل محتوى، حتى لو كانت خطة Cloudflare المجانية فقط، لتعمل كواجهة أمامية لعمليات التحميل على S3 حتى لا تغرق في رسوم العرض النطاقي الصادر. إذا أمكن، فعّل Origin Shield لتقليل حركة المرور الصادرة بشكل أكبر.
انتظرت حرفيًا حتى يجيب @Falco ()، حيث قام بعمل رائع في توحيد S3 مع معايير Discourse.
أنصحك باللجوء إلى خيار أرخص لاستنساخ S3. تُعد مساحات Digital Ocean الخيار الافتراضي بعد S3 إذا كان لديك كمية كبيرة من البيانات، وربما يمكنك التوجه إلى لاعبين أكبر يركزون على التخزين مثل BlackBlaze أو Wasabi لتقليل التكاليف بشكل أكبر.
سيؤدي القيام بذلك إلى إزالة معظم تكاليف النطاق الترددي، حيث تُقيم هذه الخدمات بأسعار أرخص بكثير (ولا تفرض Wasabi أي رسوم على النطاق الترددي).
أيضًا، ولتحسين الأداء، أنصحك بإضافة شبكة توصيل محتوى (CDN). لقد قمت مؤخرًا بالبحث عن CDN رخيص لأن مجتمعي يحقق ربحًا ضئيلًا فقط عبر AdSense، ووجدت أن BunnyCDN ليس الأسرع، لكنه يؤدي المهمة بشكل جيد وسهل الإعداد.
أنا متأكد تقريبًا من أن التكلفة ستكون أعلى من أي شيء آخر، حيث ستحتاج إلى إعداد شبكة نظير إلى نظير (P2P) باستخدام خادم Discourse (أو خادم بذرة) كمصدر للحقيقة* أو البذرة الرئيسية لجميع الوسائط.
سيحتاج هذا الخادم البذري إلى موارد كافية للتعامل مع كل اتصال جديد يُفتح مع كل طلب، لأن كل ملف وسائط سيكون ملف تورنت مختلفًا. أعلم أن WebRTC فعّالة وكفؤة للغاية، لكن فتح اتصال يُعد عادةً الجزء الأكثر استهلاكًا للموارد في أي تطبيق ويب.
ما لم أكن قد أغفلت شيئًا، فإن هذا الإعداد سيكون غير تافهًا ومستهلكًا للموارد بشكل كبير للمجتمعات النشطة حقًا.
تحتوي ملفات التنزيل على بذرة ملف، لذا إذا لم يكن الملف متاحًا من السرب، يتم تحميله من مصدر آخر، مثل S3.
تطبيق Discourse يقدّم فقط رابط التنزيل/المغناطيس، ولا يقوم بالبذر. المستخدمون الذين لديهم صور محملة بالفعل يقومون ببذرها، وإذا كانت أصول الوسائط تُزرع أيضًا بواسطة عملاء BitTorrent تقليديين، فيمكن استخدام تلك أيضًا. عميل التنزيل يعمل على جانب المتصفح/العميل، لذا فإن الحمل على الخادم يقتصر فقط على تقديم المزيد من جافا سكريبت.
هل يمكنك إضافة إخلاء مسؤولية للمستخدمين؟ على سبيل المثال، عندما أدخل إلى صفحتك عبر هاتفي المحمول باستخدام اتصال محدود الاستهلاك، كيف يمكنني استبعاد اتصالي المحدود من استهلاك كامل عرض النطاق الترددي الخاص بي لأن المنشور أصبح viral؟
أنت تواصل استخدام S3 كمصدر رئيسي لتحميل الملفات، وهو ما لن يوفر لك الكثير من المال في الواقع.
ما زلت بحاجة إلى وجود مُوزِّعين (seeders) يخدمون الاتصالات، وتحتاج إلى مُوزِّعين غير موثوقين بسبب اختلاف سرعات الإنترنت.
بالتأكيد، يمكنك ببساطة إضافة مفتاح تبديل في نافذة حوار، أو جعله جزءًا من التفضيلات، أو استخدام أداة مثل Privacy Badger لمنع تحميل المكتبة من الأساس. أو يمكنك اكتشاف ما إذا كان المتصفح يعمل على جهاز محمول وتعطيل الميزة بالكامل. هناك العديد من الخيارات المتاحة.
يعمل الأمر بشكل يشبه التخزين المؤقت. إذا لم يتم بذل الوسائط (Seeding)، فسيتم جلبها من المصدر على الويب (وهو S3 في حالتنا). ومع ذلك، نظرًا لأن WebTorrent يمكنه أيضًا جلب البيانات من عملاء تورنت تقليديين مثل Transmission و rtorrent وغيرها، فيمكننا الاعتماد على عدد قليل من الموزعين (مثلي) الذين يقومون ببذلة كمية كبيرة من المحتوى عبر اتصال منزلي. في الواقع، تحتاج فقط إلى حفنة من الموزعين لجعل هذا النظام مجديًا.
لم يعد الأمر مستحيلاً الآن، بل لقد جعلت الميزة معقدة إلى حد لا تتحمله إلا ميزات قليلة جداً. على سبيل المثال، قام فريق Discourse بإسقاط دعم IE11 بسبب المتاعب التي تسببها في صيانة الكود. تخيل منطقاً من هذا القبيل، ربما إذا ذهبت إلى Marketplace سيجد شخص ما حلاً لذلك.
لا أرى أي فائدة حقيقية لإدراجها في النواة، وقد طلبت إضافة العديد من الأمور إلى النواة كانت أسهل بكثير في التنفيذ.
والتي تم رفضها بشكل صحيح مع شرح واضح ومنطقي (لا شكوى مني هنا).
شخصياً، لن أستخدمها ولن أهتم بجعلها تعمل؛ فاستخدام شبكة توصيل محتوى (CDN) أمامية هو أسهل وأكثر موثوقية وأقل تكلفة، ثم تنسى الأمر تماماً.
)، حيث قام بعمل رائع في توحيد S3 مع معايير Discourse.
