Avec la philosophie 1RTT de Discourse, je pense qu’il serait temps de réécrire le code de service des images d’avatar.
Les images d’avatar doivent être traitées comme n’importe quel autre téléchargement d’image. Redimensionnées lors du téléchargement, stockées et servies directement à partir du système de fichiers/S3/CDN.
La méthode actuelle de Discourse utilise une méthode de proxy pour servir les images d’avatar. Cette approche crée des allers-retours HTTP inutiles et des problèmes d’adresses IP.
Voici un aperçu des requêtes d’avatar :
Le HTML initial de Discourse est rendu.
Le navigateur détecte une image d’avatar et demande une image au serveur Discourse.
Le serveur Discourse agit comme un proxy et demande l’image au stockage local de fichiers/S3/CDN.
Le serveur Discourse reçoit l’image.
Le serveur Discourse envoie l’image au navigateur.
Chaque avatar personnalisé entraîne 1 aller-retour HTTP supplémentaire et le temps de traitement du serveur associé. Un sujet typique ou une liste de sujets peut contenir plus de 30 images d’avatar personnalisées. Sur mon site, cela se traduit par 10 000 à 20 000 RTT supplémentaires et une charge serveur associée par jour qui pourraient être évitées.
De plus, les images d’avatar sont appelées directement depuis le serveur. Pour toute protection au niveau du CDN, il faut autoriser l’adresse IP. Cela nécessite d’autoriser les passerelles plutôt que les adresses IP des serveurs. Les sociétés d’hébergement modifient régulièrement leur trafic réseau pour équilibrer la charge. Mon adresse IP de passerelle changera/évoluera. Le logiciel ne devrait pas dépendre de la mise à jour de l’adresse IP pour que les images d’avatar de base fonctionnent. Ceci est basé sur l’incident suivant dans le support, Avatar Proxy and CDN Hot-Link Protection.
D’un point de vue performance et simplicité, pouvons-nous faire servir les images d’avatar directement depuis le stockage de fichiers désigné de Discourse ?
C’est en effet une partie très compliquée de l’application @LotusJeff.
Pour remédier à certaines de ses lacunes, nous avons récemment développé un moyen de réduire ces allers-retours dans notre hébergement, mais je ne pense pas que nous l’ayons jamais documenté ici. Existe-t-il des documents publics à ce sujet @david ?
Oui, nous avons ce GlobalSetting que vous pouvez activer en définissant la variable d’environnement DISCOURSE_REDIRECT_AVATAR_REQUESTS=true
Ensuite, au lieu de faire du proxy, les requêtes d’avatar seront servies avec une redirection 302 vers le stockage de fichiers.
En soi… ce n’est pas vraiment une bonne idée. Cela signifie que les navigateurs doivent effectuer deux allers-retours HTTP complets pour chaque avatar. Donc, bien que cela puisse résoudre votre problème de « protection contre le hotlinking »… je ne vous recommanderais pas de l’activer. Cela dégradera l’expérience de vos utilisateurs.
Nous utilisons ce paramètre sur notre hébergement discourse.org. Mais nous le complétons avec une fonction Lambda exécutée sur notre CDN Cloudfront. Elle détecte le 302 et effectue le proxy elle-même. Essentiellement : nous déplaçons le proxy de nos serveurs d’application vers le CDN.
Quant à la question plus générale de savoir « si nous pouvons faire en sorte que les avatars pointent directement vers l’actif ». C’est délicat car les URL d’avatar sont intégrées dans tous les anciens messages (par exemple, les citations). Les URL dynamiques /user-avatar/ nous permettent de faire en sorte que celles-ci fonctionnent lorsqu’un utilisateur modifie son avatar. Je crains que nous n’ayons pas l’intention de modifier ce système.
S’il existe un moyen simple et à faible risque de faire fonctionner le proxy existant pour votre cas d’utilisation (par exemple, ajouter un GlobalSetting qui insère un en-tête HTTP spécifique dans toute requête de proxy d’avatar), nous pourrions alors envisager d’accepter une PR pour le changement.
Aucune des options mentionnées ci-dessus n’est réalisable ou préférée dans mon environnement actuel. J’aimerais aider à résoudre cette partie convolutive de l’application, mais je suis très novice dans cette stack technologique.
La seule assistance que je peux apporter maintenant est en utilisant mes anciennes compétences en BA et en gestion de développement. Donc, dans l’esprit de me sentir utile, voici mes réflexions.
Lorsque je regarde un problème technique, je regarde d’abord les hypothèses possibles qui rendraient une solution plus difficile.
Une hypothèse serait de sauvegarder une image d’avatar mise à jour sous un nouveau nom de fichier. La personne n’a qu’un seul avatar. Nous ne conservons pas un enregistrement des noms d’avatar. Je suggère que lorsque quelqu’un met à jour son avatar, il soit enregistré en utilisant le même nom de fichier que l’avatar existant. C’est en gros ce que fait le lien /user-avatar/. Au lieu d’avoir une solution temporaire, appliquez cette logique lors de la création/mise à jour de l’avatar. Cela résoudrait les préoccupations concernant les anciens posts pour les futures publications intégrées.
Est-ce un changement massif ? Non, ce changement pourrait être réalisé sur plusieurs mois, en améliorant lentement la performance du site. Mes équipes de développement avaient toujours une liste opportuniste de modifications pour chaque bloc de code. Nous voulions faire ces améliorations, mais elles n’étaient pas critiques pour être faites individuellement. Lorsqu’on ouvrait le code pour un autre développement, le développeur effectuait aussi des changements opportunistes. Cela minimisait nos tests et erreurs en réduisant le nombre de fois où le code était ouvert et mis à jour.
Je proposerais de décomposer ce projet en les phases suivantes :
Mettre à jour la logique d’enregistrement des images d’avatar pour remplacer toute mise à jour utilisant le nom de fichier actuel.
Remplacer toutes les utilisations des images d’avatar par une fonction standard qui utilise le système de stockage/distribution de fichiers préféré de Discourse. Ces étapes pourraient être réalisées sur plusieurs mois, en passant progressivement à la nouvelle logique de présentation de l’avatar.
Une fois les deux premières étapes terminées, fournir à la communauté les instructions et extraits de code pour changer et retoucher les images d’avatar historiques dans le HTML intégrée vers leur système de fichiers préféré. Cela dépendrait du choix de chaque propriétaire de site Discourse. (Ces instructions et extraits seraient utiles pour faire des modifications HTML brutes)
Je suis sûre que vous avez déjà considéré tout cela. Je sais aussi que la correction du code plus ancien ne remonte jamais en priorité.
Si je peux faire quelque chose pour aider dans cet effort, n’hésitez pas à me le faire savoir.
P.S. J’apprécie l’offre d’une PR pour un réglage global en-tête. Je vais faire quelques recherches supplémentaires et revenir avec des exigences plus précises. Merci pour votre aide.
Malheureusement, si le fichier est mutable, cela signifierait que nous ne pourrions plus activer la mise en cache infinie de l’actif dans le CDN et les navigateurs des utilisateurs finaux.
Il existe des stratégies pour faire fonctionner quelque chose comme cela sans trop nuire aux performances… par exemple, la directive stale-while-revalidate. Mais cela entraîne ses propres coûts et implications en matière d’expérience utilisateur.