Il s'agit d'un mémo d'enquête lorsque le traitement de l'application Rails exécutée sur Heroku était lent. En conclusion, la partie de stockage cloud de GCP utilisée pour le stockage d'images était le goulot d'étranglement.
Je construis et exploite un site Web de loisirs en utilisant Rails avec le plan gratuit Heroku. Depuis le début, le processus n'était pas très rapide, mais j'avais l'habitude de mettre en cache SQL avec Redis, alors j'ai pensé que ce serait comme ça s'il était gratuit.
Cependant, j'ai remarqué que seules certaines pages étaient plus rapides que d'autres, alors j'ai décidé d'enquêter sur la cause.
Bien que ce soit une méthode générale, j'ai décidé de sortir le journal avec la commande suivante et de vérifier le temps de traitement.
heroku logs --tail
Par défaut, Rails vous donne différents temps de traitement dans le journal DEBUG, j'ai donc décidé de vérifier cela en premier.
Au début, je pensais que le SQL de la partie non mise en cache était lent, Quant à SQL, le cache fonctionnait et je n'ai pas trouvé de requêtes lentes.
Cependant, à la place, il y avait certains journaux où le temps de traitement était de 100 ms ou plus, comme indiqué ci-dessous.
GCS Storage (169.9ms) Checked if file exists at key: variants/xxxx
Le site a téléchargé l'image sur GCS, et je pouvais deviner que la partie était liée. Vous pouvez également voir que la fonction correspondante d'Active Storage est affectée par des mots-clés tels que variant.
Variant
En ce qui concerne cette variante, j'aimerais que vous voyiez les documents de référence ci-dessous, mais en termes simples, c'est une fonction de redimensionnement, etc. sans utiliser l'image téléchargée telle quelle. Référence
Si vous utilisez cette fonction, vous n'avez pas à vous soucier de mettre en œuvre un traitement de redimensionnement, etc., et c'est une fonction très pratique qui enregistre l'image redimensionnée au premier accès et la réutilise en arrière-plan. Cependant, cette fois, il semble que la fonction de Ki fasse quelque chose de mal.
J'ai décidé qu'il serait difficile d'enquêter plus avant, alors j'ai cherché sur Google si d'autres symptômes similaires se produisaient pour le moment.
En conséquence, j'ai trouvé des choses qui semblaient être des symptômes similaires, tels que S3 d'AWS.
https://stackoverflow.com/questions/49415911/activestorage-checking-if-file-exists-is-slow https://github.com/rails/rails/issues/32548 https://github.com/rails/rails/pull/37901
Quand je l'ai lu en diagonale avec ma faible maîtrise de l'anglais, j'ai fait le jugement suivant. (Je m'excuse si je me trompe.)
En regardant ce qui précède, je pensais que la dernière version résoudrait le problème, mais malheureusement, la 6.1 n'est pas encore sortie ...
En conclusion, j'ai décidé d'arrêter le processus de compression par variante et d'utiliser l'image d'origine. En ce qui concerne l'image d'origine, il est estimé que ce ne sera pas un problème car elle est redimensionnée manuellement et corrigée avec un outil d'image, etc. avant le téléchargement.
En conséquence, le journal d'origine qui prenait plus de 100 ms a disparu et a été remplacé par le traitement de 1 ms suivant, et je sens que la vitesse est devenue plus rapide.
GCS Storage (1.5ms) Generated URL for file at key: xxxx
C'est donc parce qu'il a fallu beaucoup de temps pour utiliser l'image traitée par Active Storage dans Cloud Storage (GCS). Nous avons décidé de le traiter de manière délicate, en n'utilisant pas la fonction sans prendre des mesures fondamentales.
Il semble que Rails 6.1 sortira bientôt, je voudrais donc utiliser à nouveau la fonction après la mise à jour.
C'est le stockage actif qui peut facilement utiliser le stockage cloud tel que S3 et GCS, mais grâce à diverses dissimulations dans les coulisses, il s'est avéré que cela affecte les performances dans des endroits qui ne peuvent pas être vus.