لدينا فئة #Announcements يتم فيها اشتراك جميع أعضائنا تلقائيًا لمشاهدة المنشور الأول.
يتيح لنا ذلك جدولة نشر المنشورات في تلك الفئة في أوقات/تواريخ محددة.
بدوره، يتم إرسال الإعلان عبر البريد الإلكتروني إلى حوالي 25 ألف عضو.
المشكلة التي نواجهها هي أن رسائل البريد الإلكتروني تستغرق أكثر من ساعة لإرسالها، وهو أمر غير مثالي للإعلانات ذات الأهمية الزمنية.
إذا قمت بمراقبة Sidekiq، يمكنني رؤية عداد “Scheduled” يجمع كل رسائل البريد الإلكتروني الفردية واحدة تلو الأخرى، وبمجرد وصوله إلى حوالي 20 ألفًا، يقوم بنقلها إلى علامة التبويب “Enqueued”، ثم تبدأ في الإرسال في النهاية.
هل يمكنني تسريع هذه العملية بأي شكل من الأشكال؟
بالنسبة لرسائل البريد الإلكتروني ذات الأهمية الزمنية، سيكون من الجيد إرسالها أسرع بحوالي 100 مرة مما هي عليه حاليًا
تأخير أثناء إدراج وظائف البريد الإلكتروني في قائمة الانتظار
وقت المعالجة لإرسال البريد الإلكتروني الفعلي
بالنسبة للأول، لست متأكدًا بنسبة 100% من هذا، لكن أعتقد أن تقليل email_time_window_mins يعني أن الإشعارات يتم إدراجها في قائمة الانتظار في وقت أقرب.
بمجرد جدولة وظائف البريد الإلكتروني، تعمل عوامل Sidekiq الخاصة بك على معالجتها واحدة تلو الأخرى. زيادة عوامل Sidekiq (اضبط DISCOURSE_SIDEKIQ_WORKERS من 5 إلى 10 أو 15 أو 20 حسب سعة الخادم) يعني معالجة المزيد من المهام في نفس الوقت، وبالتالي يتم إفراغ قائمة الانتظار بشكل أسرع بمرتين/3 مرات/4 مرات.
لا أعرف كيف يعمل الواجهة الخلفية بأدق التفاصيل، ولكن email_time_window_mins هو مجرد إعداد تأخير قبل إرسال البريد الإلكتروني الأول. خلال هذا الوقت، قد “يتنازل” أي مستخدم تم تعيينه لتلقي البريد الإلكتروني عن البريد الإلكتروني إذا كان نشطًا في غضون فترة النافذة (المصطلح الرسمي: تم تخطي البريد الإلكتروني؛ سبب التخطي: شوهد المستخدم مؤخرًا).
التأخير الافتراضي هو 10 دقائق، مما يعني أن المنشور يجب أن يكون مباشرًا لمدة 10 دقائق، وبعد ذلك فقط سيتم إرسال رسائل البريد الإلكتروني.
مشكلة ريتشي هي الفارق الزمني بين البريد الإلكتروني الأول والأخير… تأخير لمدة ساعة. هذا ربما بسبب الكم الهائل من رسائل البريد الإلكتروني التي تحتاج إلى إرسالها، على الرغم من أنني لا أستطيع الجزم بذلك أيضًا.
تغيير الإعداد أعلاه سيسرع فقط إرسال البريد الإلكتروني الأول، ولكنه لن يعالج مدة اكتمال الدفعة الكاملة البالغة 22000 بريد إلكتروني.
ما هو الإعداد الموصى به، بالاعتماد الواضح على قدرة البنية التحتية؟
هل يمكن أن يؤدي الإعداد العالي إلى مشاكل في الخادم من حيث الحمل أو غير ذلك؟
يعتمد هذا بنسبة 100٪ على سعة الخادم لدى OP - الكثير جدًا سيؤدي إلى إبطاء الأمور، والقليل جدًا سيستغرق وقتًا أطول للمعالجة.
بالنظر إلى أن رسم بياني لوحدة المعالجة المركزية يصل إلى 40٪ (هل هذا من وحدة معالجة مركزية واحدة أم من السعة الإجمالية؟) ربما أبدأ بزيادته إما بمقدار الضعف (محافظ) أو 3 أضعاف (عدواني) وأرى ما يحدث، اعتمادًا على مدى تحمل المخاطر للتباطؤ.
env:
LANG: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## كم عدد طلبات الويب المتزامنة المدعومة؟ يعتمد على الذاكرة وأنويتها.
## سيتم تعيينه تلقائيًا بواسطة bootstrap بناءً على وحدات المعالجة المركزية المكتشفة، أو يمكنك تجاوزها
UNICORN_WORKERS: 8
## تمت إضافة هذا السطر في 04/10/25
## REF: https://meta.discourse.org/t/is-there-a-way-i-can-send-email-notifications-faster/383103/12
DISCOURSE_SIDEKIQ_WORKERS: 7
سأقوم بإعادة البناء لاحقًا هذا الأسبوع وتوقيت إرسال رسائل البريد الإلكتروني
فقط حتى أعرف أن تغييري قد تم تطبيقه، هل أفكر بشكل صحيح في أن قيمة Threads هذه يجب أن تزيد من 5 إلى 7؟
إنه لا يحد من نفسه بحد ذاته ولكن كل عامل sidekiq سيعالج وظيفة واحدة في كل مرة، لذلك إذا كان لديك 22000 بريد إلكتروني في انتظار الإرسال، فسيتم معالجة سبعة منها في وقت واحد.
من ناحية الأشياء السخيفة، من المحتمل أن الخادم لن يتمكن من مواكبة الأمر إذا قمت بتعيين العدد إلى 1000 عامل متوازي. لذا فالأمر يتعلق بإيجاد رقم يناسب جميع احتياجاتك:
معالجة أكبر عدد ممكن من المهام في نفس الوقت لتجاوز الـ 22000 بريد إلكتروني بشكل أسرع
ولكن لا تستهلك كل موارد الخادم مما لا يترك شيئًا لمستخدمي الموقع
