Aktualisierung des Avatar-Bild-Servings – Proxy-Methode entfernen

Merkmal
1

Mit der 1RTT-Philosophie von Discourse ist es vielleicht an der Zeit, den Code für die Bereitstellung von Avatar-Bildern neu zu schreiben.

Avatar-Bilder sollten wie jedes andere hochgeladene Bild behandelt werden. Sie sollten beim Hochladen in der Größe geändert, gespeichert und direkt vom Dateisystem/S3/CDN bereitgestellt werden.

Die aktuelle Discourse-Methode verwendet eine Proxy-Methode zur Bereitstellung von Avatar-Bildern. Dieser Ansatz erzeugt unnötige HTTP-Roundtrips und Herausforderungen bei der IP-Adressierung.

Hier ist ein Überblick über Avatar-Anfragen:

  • Das anfängliche Discourse-HTML wird gerendert.
  • Der Browser erkennt ein Avatar-Bild und fordert ein Bild vom Discourse-Server an.
  • Der Discourse-Server fungiert als Proxy und fordert das Bild aus dem lokalen Dateispeicher/S3/CDN an.
  • Der Discourse-Server empfängt das Bild.
  • Der Discourse-Server sendet das Bild an den Browser.

Jeder benutzerdefinierte Avatar hat 1 zusätzlichen HTTP-Roundtrip und die damit verbundene Serververarbeitungszeit. Ein typisches Thema oder eine Themenliste kann mehr als 30 benutzerdefinierte Avatar-Bilder enthalten. Auf meiner Website führt dies zu 10.000 bis 20.000 zusätzlichen RTTs und einer damit verbundenen Serverlast pro Tag, die vermieden werden könnten.

Darüber hinaus werden die Avatar-Bilder direkt vom Server aufgerufen. Um einen CDN-Schutz auf CDN-Ebene zu implementieren, ist eine Whitelisting der IP-Adresse erforderlich. Dies erfordert das Whitelisting von Gateways anstelle von Server-IP-Adressen. Hosting-Unternehmen nehmen regelmäßig Änderungen vor, um den Netzwerkverkehr auszugleichen. Meine Gateway-IP-Adresse wird sich ändern/weiterentwickeln. Die Software sollte sich nicht auf die Aktualisierung der IP-Adresse verlassen, damit grundlegende Avatar-Bilder funktionieren. Dies basiert auf dem folgenden Vorfall im Support: Avatar Proxy und CDN Hot-Link Protection

Aus Sicht der Leistung und Einfachheit, können Avatar-Bilder direkt aus dem dafür vorgesehenen Datenspeicher von Discourse bereitgestellt werden?

5 „Gefällt mir“
2

Dies ist tatsächlich ein sehr komplizierter Teil der App @LotusJeff.

Um einige seiner Mängel zu beheben, haben wir kürzlich eine Möglichkeit entwickelt, diese Rundreisen in unserem Hosting zu reduzieren, aber ich glaube nicht, dass wir es hier jemals dokumentiert haben. Gibt es dazu öffentliche Dokumente @david?

4 „Gefällt mir“
3

Ja, wir haben diese globale Einstellung, die Sie aktivieren können, indem Sie die Umgebungsvariable DISCOURSE_REDIRECT_AVATAR_REQUESTS=true setzen.

Dann werden Avatar-Anfragen statt über ein Proxy mit einer 302-Umleitung zum Dateispeicher bedient.

An sich… ist das keine gute Idee. Das bedeutet, dass Browser für jeden Avatar zwei vollständige HTTP-Roundtrips machen müssen. Es mag also Ihr Problem mit dem “Hotlinking-Schutz” lösen… aber ich würde Ihnen nicht empfehlen, es zu aktivieren. Es wird die Erfahrung für Ihre Benutzer verschlechtern.

Wir verwenden die Einstellung auf unserem Discourse.org-Hosting. Aber wir ergänzen sie mit einer Lambda-Funktion, die auf unserem Cloudfront CDN läuft. Sie erkennt die 302 und führt das Proxying selbst durch. Im Wesentlichen: Wir verlagern das Proxying von unseren Anwendungsservern auf das CDN.

Was die allgemeinere Frage betrifft, ob wir Avatare so ändern können, dass sie direkt auf das Asset verlinken. Das ist knifflig, da Avatar-URLs in allen historischen Beiträgen (z. B. Zitaten) eingebettet sind. Die dynamischen /user-avatar/-URLs ermöglichen es uns, diese auch dann funktionsfähig zu halten, wenn ein Benutzer seinen Avatar ändert. Ich fürchte, wir haben keine Pläne, dieses System zu ändern.

Wenn es eine einfache, risikoarme Möglichkeit gibt, das bestehende Proxying für Ihren Anwendungsfall funktionsfähig zu machen (z. B. eine globale Einstellung hinzufügen, die eine bestimmte HTTP-Kopfzeile in Avatar-Proxy-Anfragen einfügt), dann könnten wir die Annahme eines PR für die Änderung in Betracht ziehen.

3 „Gefällt mir“
4

Keines der oben genannten Optionen ist in meiner aktuellen Umgebung machbar oder bevorzugt. Ich würde gern bei der Lösung dieses verworrenen Teils der Anwendung helfen, bin aber sehr neu in diesem Tech-Stack.

Die einzige Unterstützung, die ich jetzt bieten kann, ist die Nutzung meiner alten BA- und Dev-Mgt-Fähigkeiten. Daher sind hier meine Gedanken, um das Gefühl zu erzeugen, dass ich helfe.

Wenn ich ein technisches Rätsel betrachte, schaue ich zuerst auf mögliche Annahmen, die eine Lösung erschweren könnten.

Eine Annahme ist, ein aktualisiertes Avatar-Bild unter einem neuen Dateinamen zu speichern. Die Person hat nur ein Avatar. Wir speichern keine Aufzeichnungen der Avatar-Namen. Ich schlage vor, dass beim Aktualisieren des Avatar-Bildes dasselbe Dateiformat wie das bestehende Avatar verwendet wird. Das ist im Grunde das, was der Link /user-avatar/ macht. Anstatt eine Umgehung zu haben, sollte diese Logik beim Erstellen/Aktualisieren des Avatars durchgeführt werden. Dadurch könnten die Bedenken bei historischen Beiträgen für zukünftige gebackene Beiträge gelöst werden.

Ist das eine große Änderung? Nein, diese Änderung könnte über Monate schrittweise umgesetzt werden, um die Site-Performance langsam zu verbessern. Meine Entwicklerteams haben immer eine opportunistische Code-Liste für jeden Codeblock gehabt. Wir wollten diese Verbesserungen vornehmen, aber sie waren nicht kritisch, um sie einzeln durchzuführen. Wenn der Code aus einem anderen Grund geöffnet wurde, hat der Entwickler auch opportunistische Änderungen vorgenommen. Das minimierte unsere Tests und Fehler, indem es die Anzahl der Code-Öffnungen und -Aktualisierungen reduzierte.

Ich würde dieses Projekt in folgende Phasen unterteilen:

  1. Aktualisierung der Logik zum Speichern von Avatar-Bildern, um jegliche Bildaktualisierungen mit dem aktuellen Dateinamen zu ersetzen.
  2. Ersetzen aller Verwendungen von Avatar-Bildern durch eine Standardfunktion, die das bevorzugte Dateispeicher- und Auslieferungssystem von Discourse nutzt. Diese könnten über Monate umgesetzt werden, um schrittweise zur neuen Avatar-Darstellungslogik zu migrieren.
  3. Sobald die ersten beiden Phasen abgeschlossen sind, die Community mit Schritten und Code-Snippets versorgen, um historische Avatar-Bilder in gebackenem HTML in ihr bevorzugtes Dateisystem zu ändern. Dies würde den einzelnen Discourse-Website-Betreibern die Wahl lassen, dies umzusetzen (diese Code-Anweisungen und Snippets wären nützlich, um Roh-HTML-Änderungen durchzuführen).

Ich bin sicher, dass Sie all das bereits berücksichtigt haben. Ich weiß auch, dass das Beheben älterer Codes nie oberste Priorität hat.

Wenn ich in irgendeiner Weise bei dieser Aufgabe helfen kann, lassen Sie es mich bitte wissen.

Ps. Ich schätze das Angebot, einen PR für eine globale Kopfzeileinstellung zu machen. Ich werde noch etwas zusätzliche Recherche betreiben und mit einer genaueren Anforderungsbeschreibung zurückkommen. Vielen Dank für Ihre Unterstützung.

5

Leider bedeutet dies, wenn die Datei veränderbar ist, dass wir die unendliche Zwischenspeicherung des Assets im CDN und in den Browsern der Endbenutzer nicht mehr aktivieren können.

Es gibt Strategien, um so etwas zu ermöglichen, ohne die Leistung zu sehr zu beeinträchtigen … z. B. die Direktive stale-while-revalidate. Aber das bringt eigene Kosten und UX-Implikationen mit sich.

1 „Gefällt mir“