Hallo,
ich bin gerade zu R2 migriert und alles hat perfekt geklappt. Alle Bilder haben den S3-CDN-URL-Link. Allerdings ist mir ein Problem aufgefallen: Avatare laden sehr lange. Im Durchschnitt dauert es etwa 3 bis 4 Sekunden, egal ob ich auf den Avatar eines Benutzers klicke oder in einen Beitrag schaue. Ist das normal?
Hmm, ich vermute, es könnte eines von drei verschiedenen Problemen sein, aber das Wahrscheinlichste ist für mich das Echtzeit-Resizing.
Als du deine Uploads auf R2 migriert hast, wurden die Originalbilder verschoben. Discourse verwendet jedoch viele verschiedene Avatar-Größen (z. B. 45 Pixel für Beiträge, 120 Pixel für die Benutzerkarte).
Wenn diese spezifischen, optimierten Größen nicht perfekt migriert wurden oder noch nicht generiert wurden, muss Discourse sie synchron generieren, sobald der Benutzer auf sie klickt:
Zur Überprüfung: Aktualisiere die Seite hart (Hard-Refresh). Wenn der Avatar beim ersten Mal 3–4 Sekunden benötigt, beim zweiten Mal aber sofort lädt, ist dies genau das, was passiert.
Zur Behebung: Dies wird sich von selbst beheben, während Benutzer browsen und die Größen generiert werden. Du kannst es jedoch sofort beheben, indem du den Server anweist, alle Avatares im Hintergrund vorab zu generieren. Dazu verbindest du dich per SSH mit deinem Server und führst folgenden Befehl aus:
./launcher enter app
rake avatars:refresh
Wenn die Avatares jedes Mal, auch nach mehrfachen Aktualisierungen, 3–4 Sekunden benötigen, liegt wahrscheinlich ein Netzwerk-Timeout vor.
Die Cloudflare-R2-API-Endpunkte sind Dual-Stack, das heißt, sie verwenden sowohl IPv4 als auch IPv6. Wenn dein Server-Droplet eine IPv6-Adresse zugewiesen hat, das IPv6-Gateway des Hosts jedoch nicht richtig geroutet ist, versucht die interne Verbindung von Ruby zum R2-Bucket zuerst IPv6, hängt für 3 Sekunden (dies ist das Standard-TCP-Timeout von Linux), schlägt fehl und gelingt dann sofort über IPv4.
Zur Überprüfung: Verbinde dich per SSH mit dem Server und führe folgenden Befehl aus:
curl -I -6 https://cloudflare.com
Wenn er einige Sekunden lang hängt und fehlschlägt, ist die IPv6-Verbindung des Servers defekt, was dazu führt, dass jede interne S3-API-Abfrage eine Verzögerung von 3 Sekunden erfährt.
Zur Behebung: Du musst entweder das IPv6-Routing in deinem Host-Steuerpanel reparieren oder IPv6 auf dem Droplet möglicherweise vollständig deaktivieren.
Wenn deine Site so konfiguriert ist, dass sie auf Gravatar-Updates überprüft, wird sie möglicherweise Gravatars externe Server anpingen, bevor der Avatar gerendert wird. Wenn der Server eine langsame ausgehende Verbindung hat (was oft auch mit DNS oder IPv6 zusammenhängt), wird das Rendern des Avatars wahrscheinlich blockiert.
Zur Überprüfung: Führe folgenden Befehl auf deinem Server aus:
curl -I -6 https://gravatar.com
Wenn er 3 Sekunden lang hängt, ist IPv6 defekt (siehe oben).
Behebung im Zusammenhang mit Gravatar: Gehe in deinen Discourse-Einstellungen zu Gravatars automatisch herunterladen, schalte es vorübergehend aus und prüfe, ob dies das Problem behebt. Ich denke nicht, dass dies das Problem ist, aber wenn doch, kannst du die Einstellung ausgeschaltet lassen, das IPv6-Routing wie in Punkt 2 oben reparieren oder den DNS-Resolver ändern.
Vielen Dank für Ihre schnelle Antwort. Ich glaube, ich habe den Befehl rake avatars:refresh bereits zuvor versucht, bin mir aber nicht absolut sicher.
Was bei mir früher funktionierte, um das Avatar-Bild sofort zu sehen, war ein erster Klick darauf; beim zweiten Klick öffnete es sich sofort. Das liegt aber wahrscheinlich am Caching. Außerdem habe ich gerade Ihren zweiten Tipp getestet, und er ergibt eine „HTTP/2 301“-Antwort mit mehreren weiteren Zeilen. Gleiches gilt für Tipp 3. Ich werde avatars:refresh in ein paar Tagen erneut ausführen, da ich zuvor ein Snapshot wiederherstellen musste. Nochmals vielen Dank!
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
Ja, angesichts deiner Antwort bin ich fast sicher, dass es sich um Problem Nr. 1 handelt, da die Ergebnisse des curl-Befehls für Cloudflare und Gravatar wie erwartet ausfallen. Probiere rake avatars:refresh einfach aus, wann immer es dir passt, und lass mich wissen, ob es funktioniert.
Hey Lilly, ich habe immer noch das gleiche Problem. Selbst nach dem Ausführen von rake avatars:refresh tritt der Fehler weiterhin auf. Auch bei /latest besteht das gleiche Problem. Ich habe versucht, den Cache sowohl im Browser als auch bei Cloudflare zu leeren, aber bisher ohne Erfolg. Muss ich vielleicht noch etwas warten? Ich teste das auf einem Forum mit 4500 Benutzern.
lösche deine Browser- oder Cloudflare-Caches nicht mehr – wenn du rake avatars:refresh für so viele Benutzer ausführst, geschieht das nicht sofort. Stattdessen werden Tausende von Jobs in Sidekiq eingereiht, die im Hintergrund verarbeitet werden, was je nach CPU-Leistung deines Servers mehrere Stunden dauern kann. Entschuldige dafür, ich hätte Sidekiq erwähnen und darauf hinweisen sollen, dass es je nach Anzahl der Benutzer eine Weile dauern kann.
Gehe zu your-forum.com/sidekiq/queues und beobachte die Warteschlange. Warte, bis sie vollständig geleert ist. Sobald Sidekiq fertig ist, sollten alle Größen dauerhaft in deinem R2-Bucket gespeichert sein, und ich denke, die Ladezeit deiner Avataren sollte sich wieder normalisieren.
Ok, ich glaube, da läuft etwas anderes. Ich habe nichts in meinen Warteschlangen. Aber wenn ich auf das Avatar eines beliebigen Benutzers klicke, erscheint Folgendes in ‘tail -f log/production.log’: Sent file /var/www/discourse/tmp/avatar_proxy/3689d91eb5e1013beef831c585b5e62edeeecbd6.jpeg (0.2ms)
Oh wow, okay. Das ist höchstwahrscheinlich der entscheidende Hinweis und deutet auf ein anderes Problem hin.
„avatar_proxy
Die URL, die ich erhalte, zeigt die S3-CDN-URL an, und ich kann das Bild im Browser öffnen.
Ich werde S3 vorerst ignorieren, da ich es derzeit nicht wirklich brauche.
Ich nutze Advinservers schon seit langer Zeit.
Vielen Dank für deine Hilfe, das schätze ich sehr.
Ich habe die weiteren Tests abgeschlossen und kann bestätigen, dass das Problem nicht mit R2 zusammenhängt. Das gleiche Verhalten (langsame Ladezeiten der Avatare in Beiträgen und beim Klicken auf einen Benutzernamen) tritt auch bei einer korrekt konfigurierten AWS S3 auf. Es handelt sich auch nicht um ein Firewall-Problem, wie „ufw status“ bestätigt, dass die Firewall derzeit deaktiviert ist. Ich plane, dieses Wochenende weitere Tests in einer Staging-Umgebung durchzuführen, in der ich das Forum länger am Laufen halten und bei Bedarf ohne Probleme offline nehmen kann.
Haben Sie sowohl Site- als auch S3-CDNs konfiguriert?
Ja, ich verwende beides. Der Bucket ist mit CloudFront für die S3-CDN-URL verbunden, und dasselbe gilt für die Discourse-CDN-URL.
Für die R2-Tests habe ich die Discourse-CDN-URL nicht verwendet.
Außer bei dem, der nicht funktioniert?
Und bei der R2-Konfiguration ohne Discourse-CDN hast du Probleme?
Ich werde nicht vorgeben, genau zu verstehen, was dein Problem ist oder wie die Avatar-Bilder genau funktionieren, aber ich würde die CDN-Verbindung einrichten, bevor du weitere Tests durchführst. Es könnte sein, dass das Problem darin liegt, dass du zu einem neuen Bucket gewechselt bist und die Bilder neu generiert werden müssen.
Avatars hier werden von einer Discourse-CDN geladen: https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/lilly/48/555832_2.png
Laden die Benutzerprofile schneller, nachdem sie das erste Mal geladen wurden?
Auch hier verspreche ich nicht, dass ich es verstehe und habe den Code nicht angesehen, aber ich vermute, dass diese von der Discourse-CDN ausgeliefert werden und Discourse darauf vertraut, dass nachfolgende Anfragen von der CDN geladen werden. Ich denke, das erklärt, warum es bei der R2-Version ohne Discourse-CDN nicht funktioniert (oder langsam ist).
vielleicht verstehe ich nicht, was du hier meinst, aber ich habe 2 Sites, die R2-Objektspeicher ausführen und dieses Problem nicht haben. 
Haben sie keine Discourse-CDNs? Wenn nicht, liege ich falsch. Wenn ja, könnte es sein, dass das Fehlen eines Discourse-CDNs (wenn man einen S3-Bucket hat?) dieses Problem verursacht.
Aber es scheint seltsam, dass sich Avatare mit S3 anders verhalten als ohne.
Tatsächlich habe ich dies mit 4 verschiedenen Konfigurationen getestet:
R2 ohne Discourse-CDN
R2 mit Discourse-CDN
AWS S3 mit Discourse-CDN
AWS S3 ohne Discourse-CDN
In allen Fällen habe ich die S3-CDN-URL verwendet: files.mydomain.com.
Für die Fälle mit dem Discourse-CDN habe ich verwendet: cdn.mydomain.com.
Das Problem ist, dass in jedem Szenario das Laden der Avatare immer sehr langsam ist.
Wenn ich ein Thema öffne, sehe ich, wie die Avatare nacheinander geladen werden. Dies geschieht jedoch nur einmal. Wenn ich beispielsweise zu admin/users gehe, sehe ich zunächst nur die Nicknames, und dann beginnen die Avatare nacheinander zu laden.
Wenn ich auf einen Nickname klicke, öffnet sich die Benutzerkarte, und der Avatar erscheint 3-4 Sekunden später. Dies geschieht ebenfalls nur einmal; bei einem erneuten Klick erscheint der Avatar sofort, wahrscheinlich aufgrund des Caches.
PS: Bei jedem Test stelle ich den Snapshot aus der Zeit wieder her, in der ich S3/R2 nicht verwendet habe, lösche den Bucket und beginne von vorne.
Ich vermute einfach mal, dass es nichts mit der Konfiguration des Objektspeichers zu tun hat. Ich denke, deine Avatares sind in allen vier Konfigurationen langsam, weil das Engpassproblem nicht beim Speicheranbieter liegt, sondern bei der Netzwerklatenz zwischen deinem Site-Droplet und deinem Bucket, oder weil die CPU deines Servers beim dynamischen Ändern der Bildgrößen überlastet ist. Ich kenne deine Server-/CDN-Konfiguration und die beteiligten Entfernungen nicht. Aber ich denke, sobald der Edge-Cache aufgebaut ist, sollte es keine Rolle spielen, welchen Speicher du verwendest, solange du bei einem bleibst und den Cache sich selbst aufbauen lässt. Allerdings spekuliere ich hier nur, weil ich keine anderen Ideen habe. 
Ich weiß auch nicht mehr, was ich davon halten soll. Für R2 habe ich die Region Western Europe (WEUR) verwendet, und für S3 eu-north-1. Das sind meine VPS-Spezifikationen:
AMD Turin-Prozessor (4 vCores) 8 GB DDR5 ECC-Speicher 256 GB NVMe-SSD-Speicher 5 TB Bandbreite (10 Gbit) Standort: Los Angeles, CA
Vielleicht sollte ich beim nächsten Mal mit einer Region in den USA testen? Ich glaube nicht, dass ich das mit R2 machen kann.
Das ist zu erwarten. Die Generierung aller Avatare dauert lange. Die Rake-Aufgaben sorgen dafür, dass dies geschieht, aber sie benötigen viel Zeit, insbesondere wenn es viele Benutzer gibt. Beim ersten Zugriff auf einen Benutzer wird der Avatar generiert, und es dauert einige Sekunden, bis ein externes Programm die Bilddaten in verschiedene Größen umwandelt. Danach läuft alles reibungslos. Ich denke, du musst lediglich die Rake-Aufgabe ausführen und darauf warten, dass alle Avatare in den verschiedenen Größen generiert werden?
Ja, ich glaube, darauf wollte ich hinaus, aber ich habe es vielleicht nicht richtig erklärt:
aber ich dachte, du sagtest, dass er jedes Mal langsam lädt. 
Ich glaube, jedes Mal, wenn du deine S3-Konfiguration änderst oder deinen Cache löschst, fängst du wieder von vorne an. Wenn du viele Benutzeravatare hast, wird das eine lange Zeit dauern.
