Chez Discourse, nous étions impatients d'adopter YJIT depuis que l'équipe d'infrastructure de Ruby on Rails de Shopify a déclaré qu'il était prêt pour la production. Après avoir constaté des benchmarks locaux prometteurs, nous avons commencé à exécuter nos applications Rails de production avec YJIT de Ruby 3.2 activé sur des clusters sélectionnés début mai 2023. Nous avons ensuite passé du temps à mesurer ses performances réelles. Nous sommes ravis de partager les résultats positifs que nous avons observés. Sur la base de ces conclusions, nous avons maintenant activé YJIT sur l'ensemble de notre hébergement, et les auto-hébergeurs peuvent choisir de faire de même.
Ceci est un sujet de discussion compagnon pour l'entrée originale à https://blog.discourse.org/2023/05/running-ruby-3-2s-yjit-in-production-at-discourse/
Nous avons commencé le benchmarking de Discourse+YJIT depuis novembre 2022, et nous avons commencé à faire fonctionner Meta sous YJIT de manière intermittente depuis janvier de cette année. YJIT est l’une des raisons pour lesquelles nous avons accéléré la mise à niveau de Ruby 2.7 à Ruby 3.2 en quelques mois et je suis ravi que ce soit enfin là. Et encore plus car les améliorations qui arriveront pour Ruby 3.3 s’annoncent encore meilleures !
C’est peut-être une question stupide, mais le « fichier de définition de conteneur » est-il le fichier app.yml ? Je n’ai jamais entendu cela auparavant. Merci !
Et sans aucune donnée mesurée et basé sur ce qu’un ou quelques utilisateurs ressentent et voient.
Pour moi, ce forum est plus lent depuis un moment. Je vois un cercle qui tourne un court instant presque chaque fois que j’ouvre un sujet. Bien sûr, cela peut et vient très probablement des serveurs et des distances entre les États-Unis et l’Europe. Mais Meta est plus lent qu’avant.
J’ai commencé à utiliser YJIT sur mon forum et lorsque le serveur est en Allemagne et que les utilisateurs sont finlandais, tout le monde dit que tous les sujets s’ouvrent plus rapidement. C’est en fait assez drôle car nous ne pouvons pas voir les changements de temps de chargement purs inférieurs à 200 ms.
Je réfléchis depuis un certain temps au temps de chargement de page fixe (ou cohérent). Où les temps de chargement pour chaque page et chaque utilisateur sont aussi cohérents que possible.
Les informations sur les utilisateurs finlandais sont intéressantes, cela m’a fait me demander si nous pouvions acheminer les utilisateurs en fonction de leur GEO IP ou de leur latence vers différents serveurs avec différentes charges afin de leur faire gagner du temps de réponse.
J’avoue ne pas avoir fait de tests comparatifs, mais je peux sentir une différence dans la manière dont les sujets et les fils de discussion s’ouvrent.
Cela doit être une étape positive car les utilisateurs ne m’ont pas signalé le contraire
Oui, nous ne mesurons que le temps passé à exécuter du code Ruby, à l’exclusion des requêtes de base de données et des commandes Redis dans les chronométrages.
