تستغرق الصور الرمزية وقتاً طويلاً في التحميل بعد الانتقال إلى R2 المتوافق مع S3

الدعم تثبيت
1

مرحبًا،

لقد انتقلت للتو إلى R2 وسارت كل الأمور بشكل مثالي. جميع الصور تحتوي الآن على روابط عنوان URL الخاص بشبكة توصيل المحتوى (CDN) الخاصة بـ S3. ومع ذلك، لاحظت وجود مشكلة: تستغرق الصور الرمزية (الأفاتار) وقتًا طويلاً في التحميل. في المتوسط، يستغرق ذلك حوالي 3 إلى 4 ثوانٍ، سواء عند النقر على صورة رمزية لمستخدم أو عند التصفح داخل مشاركة. هل هذا متوقع؟

2

حسناً، أعتقد أن المشكلة قد تكون واحدة من ثلاث مشكلات مختلفة، لكن الأرجح بالنسبة لي هو إعادة التحجيم الفوري.

1. إعادة تحجيم الصور الرمزية فورياً

عندما قمتَ بنقل ملفاتك المرفوعة إلى R2، تم نقل الصور الأصلية؛ ومع ذلك، يستخدم Discourse أحجاماً مختلفة للصور الرمزية (على سبيل المثال، 45 بكسل للمشاركات، و120 بكسل لبطاقة المستخدم).

إذا لم تكن هذه الأحجام المحسّنة المحددة قد نُقلت بشكل مثالي، أو لم يتم إنشاؤها بعد، فيضطر Discourse إلى إنشائها بشكل متزامن في اللحظة التي ينقر فيها المستخدم عليها:

  1. يقوم Discourse بتنزيل الصورة الرمزية الأصلية من R2 إلى الخادم المحلي.
  2. يعيد تحجيمها باستخدام ImageMagick.
  3. يرفع الحجم الجديد مرة أخرى إلى R2.
  4. يعيد توجيه المتصفح إلى العنوان الجديد، وتستغرق هذه العملية من 3 إلى 4 ثوانٍ.

للتحقق: قم بتحديث الصفحة قسرياً (hard-refresh) - إذا استغرقت الصورة الرمزية 3-4 ثوانٍ في المرة الأولى، ولكنها تُحمّل فوراً في المرة الثانية، فهذا هو بالضبط ما يحدث.

للعلاج: ستُصلح هذه المشكلة نفسها بشكل طبيعي مع تصفح المستخدمين وإنشاء الأحجام. ولكن يمكنك إصلاحها فوراً من خلال إجبار الخادم على إنشاء جميع الصور الرمزية مسبقاً في الخلفية، وذلك عن طريق الدخول إلى الخادم عبر SSH وتشغيل الأمر التالي:

./launcher enter app
rake avatars:refresh

2. مهلة IPv6 البالغة 3 ثوانٍ

إذا كانت الصور الرمزية تستغرق 3-4 ثوانٍ في كل مرة حتى بعد التحديثات المتعددة، فمن المرجح أنها تصادف مهلة اتصال بالشبكة.

نقاط نهاية واجهة برمجة تطبيقات Cloudflare R2 تدعم كل من IPv4 وIPv6 (ثنائية الطبقة). إذا كان لديك عنوان IPv6 مخصصاً لخادمك (Droplet)، ولكن بوابة IPv6 للمضيف غير موجهة بشكل صحيح، فسيحاول الاتصال الداخلي لـ Ruby مع دلو R2 استخدام IPv6 أولاً، ويتوقف لمدة 3 ثوانٍ (وهي مهلة TCP الافتراضية في Linux)، ثم يفشل وينجح فوراً باستخدام IPv4.

للتحقق: ادخل إلى الخادم عبر SSH وشغل الأمر:

curl -I -6 https://cloudflare.com

إذا توقف الأمر لبضع ثوانٍ ثم فشل، فهذا يعني أن IPv6 في الخادم معطوب، مما يتسبب في تأخير مدته 3 ثوانٍ في كل فحص داخلي لواجهة برمجة تطبيقات S3.

للعلاج: ستحتاج إما إلى إصلاح توجيه IPv6 في لوحة تحكم المضيف الخاص بك، أو ربما حتى تعطيل IPv6 على الخادم (Droplet) تماماً.

3. تأخيرات Gravatar

إذا كان موقعك مضبوطاً للتحقق من تحديثات Gravatar، فقد يقوم بمسح خوادم Gravatar الخارجية قبل عرض الصورة الرمزية. إذا كان للخادم اتصال خارجي بطيء (غالباً ما يكون ذلك مرتبطاً أيضاً بـ DNS أو IPv6)، فقد يعطل ذلك عرض الصورة الرمزية.

للتحقق: شغل الأمر التالي على خادمك:
curl -I -6 https://gravatar.com
إذا توقف الأمر لمدة 3 ثوانٍ، فهذا يعني أن IPv6 معطوب (انظر أعلاه).

الحل المتعلق بـ Gravatar: في إعدادات Discourse الخاصة بك، انتقل إلى تنزيل Gravatars تلقائياً، وقم بإيقافه مؤقتاً، وانظر إذا كان ذلك يحل المشكلة - لا أعتقد أن هذه هي المشكلة، ولكن إذا كانت كذلك، يمكنك ترك الإعداد معطلاً، أو إصلاح توجيه IPv6 كما هو موضح في النقطة 2 أعلاه، أو ربما تغيير مُحلل DNS.

3

شكرًا لك على ردك السريع. أعتقد أنني قد جربت بالفعل أمر ‘rake avatars:refresh’ من قبل، لكنني لست متأكدًا تمامًا.

ما كان يعمل معي في السابق لعرض الصورة الرمزية فورًا هو النقر عليها مرة أولى؛ وفي المرة الثانية، كانت تفتح على الفور. لكن هذا ربما يعود إلى التخزين المؤقت. كما أنني جربت للتو نصيحتك الثانية، وقد أعادت استجابة “HTTP/2 301” مع عدة أسطر أخرى. الأمر نفسه ينطبق على النصيحة الثالثة. سأقوم بتشغيل أمر avatars:refresh مرة أخرى بعد بضعة أيام، حيث كنت بحاجة إلى استعادة لقطة نظام. شكرًا لك مجددًا!

Gravatar

server: nginx
date: Mon, 22 Jun 2026 19:29:00 GMT
content-type: text/html; charset=utf-8
content-length: 0
content-language: en
expires: Wed, 11 Jan 1984 05:00:00 GMT
cache-control: no-cache, must-revalidate, max-age=0
x-redirect-by: Gravatar
location: https://en.gravatar.com/
alt-svc: h3=":443"; ma=86400
strict-transport-security: max-age=31536000; includeSubdomains; preload

CF

HTTP/2 301
date: Mon, 22 Jun 2026 19:27:00 GMT
content-type: text/html
content-length: 167
location: https://www.cloudflare.com/
cache-control: max-age=3600
expires: Mon, 22 Jun 2026 20:26:59 GMT
set-cookie: __cf_bm=eBP2aJ7Eg30nHPuvMMNxxKrgNtcNwKs0WDgnYyONeus-1782156420-1.0.1.1-sXpW27iuhGDF615cOfwNFybH4IMxgvZy3uA_3X_o..402T_3KSgT7CSymipL5RjdpGe3raWEqsVxQFFLPKRoDjfoT7B.0rqyDt.osbkOF98; path=/; expires=Mon, 22-Jun-26 19:57:00 GMT; domain=.cloudflare.com; HttpOnly; Secure; SameSite=None
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=QfYqSekEDPJHC2k%2BMjHN0cGjz172tmUWe2GSR8EgwNLh3TGjFYkQ0vwPxlzY1NcBcKFOMaAi4FlgjqjhETOOtHf%2BH9KdQSvqN3OME2Uh1i4nHIw%2Fy1qkvSpf4jxDchM7CaDW80tJkjBV4OqF"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
strict-transport-security: max-age=15780000; includeSubDomains
server: cloudflare
cf-ray: a0fda5d8ecd6b26d-LAX
alt-svc: h3=":443"; ma=86400
4

نعم، نظراً لردك، أنا شبه متأكد من أن المشكلة هي القضية رقم 1، لأن نتائج أمر curl لكل من Cloudflare وGravatar تبدو كما هو متوقع. جرّب تشغيل rake avatars:refresh في الوقت الذي يناسبك، وأخبرني إذا نجح الأمر.