Je travaille sur une importation vers Discourse en utilisant un importateur par lots. Cela fonctionne très bien pour les sujets et les messages, mais pour l’instant, le goulot d’étranglement se situe au niveau des fichiers. Nous avons environ 50 000 utilisateurs avec des avatars, et tandis que les données utilisateur sont importées dans la base de données en quelques secondes, les avatars prennent des heures à importer. Le système ne traite qu’environ un téléchargement par seconde.
Existe-t-il un moyen d’accélérer ce processus ? Je ne suis pas sûr de savoir quelle partie de cette opération est la plus lente. Si aucun fichier d’avatar n’est trouvé (photo_filename n’existait pas), l’exécution est très rapide, mais je commence à me perdre en essayant d’explorer la classe UploadCreator qui est finalement invoquée par ce code d’importation.
Nous avons plus de 600 000 pièces jointes, je suis donc très inquiet quant au temps que cela prendra pour les importer en utilisant le même appel create_upload.
upload = create_upload(u.id, photo_filename, File.basename(photo_filename))
if upload.persisted?
u.import_mode = false
u.create_user_avatar
u.import_mode = true
u.user_avatar.update(custom_upload_id: upload.id)
u.update(uploaded_avatar_id: upload.id)
else
puts "Erreur : Le téléchargement n'a pas été persisté pour #{u.username} #{photo_real_filename} !"
end
Une idée à ce sujet @neounix, puisque tu as déjà géré un importateur en masse de grande ampleur ?
Grâce à l’importateur en masse, nous avons réduit le traitement de 26 millions de publications d’une semaine à environ deux heures. Le point sensible est maintenant les pièces jointes, qui prennent plusieurs jours.
Je n’ai pas utilisé les scripts Discourse pour déplacer les fichiers eux-mêmes.
Nous avons utilisé des utilitaires de transfert de fichiers standards comme tar, gzip, sftp, rsync, etc.
Pour être honnête, nous avons utilisé divers éléments de différents scripts de migration Discourse, mais nous avons fini par écrire plus de la moitié de tout le code que nous avons utilisé lors de la migration. En effet, nous avons passé des mois à écrire du code gsub() pour nettoyer (réviser) des décennies de publications contenant du « code », révisées par des modérateurs qui avaient posté beaucoup de code au fil des ans. Tout le monde voulait que son code soit parfait, sans aucune erreur de syntaxe !
Nous pensions que les scripts fournis par Discourse étaient un excellent point de départ et nous les avons largement utilisés ; nous avons également écrit beaucoup de notre propre code basé sur ces scripts.
Désolé, peut-être que ma question a été ignorée. Nous n’avons pas besoin d’instructions sur la façon de déplacer les fichiers vers l’environnement serveur où l’importation a lieu. Nous disposons d’un script d’importation en masse que @Ghan est en train d’écrire, et nous essayons de trouver comment accélérer le transfert des pièces jointes. Le passage de l’importateur normal à un importateur en masse a permis de réduire le temps d’importation des publications d’une semaine à environ deux heures. J’espérais que quelqu’un pourrait nous indiquer la bonne direction pour gérer correctement les pièces jointes.
Désolé si j’ai mal compris votre question et que ma réponse n’a pas été utile.
Quoi qu’il en soit, je suis sûr que vous pourrez trouver la solution. Ce n’est pas de la science-fiction (ce n’est que du logiciel) et vous êtes des gens intelligents.
Bonne chance. Désolé de ne pas être plus utile. Nous avons terminé notre migration au deuxième trimestre 2020 et cette tâche (la migration) est désormais loin derrière nous.
Je ne pense pas qu’il existe de solution miracle similaire. Comme les téléchargements ne dépendent pas du traitement des publications précédentes, vous pourriez lancer plusieurs processus (par exemple, chacun couvrant une plage de dates différente) afin de réduire le temps d’exécution d’un facteur égal au nombre de processeurs que vous pouvez mobiliser (à condition que la base de données et le système de fichiers ne soient pas des goulots d’étranglement).
Il semble que, lorsque les publications sont traitées pour les pièces jointes, un certain nombre de tâches Sidekiq soient lancées pour gérer d’autres traitements sur ces publications. En conséquence, même un seul processus travaillant sur l’importation de pièces jointes parvient lentement à faire grimper la charge moyenne du serveur au-delà de 40, et ce, même avec 8 cœurs. (J’ai augmenté le nombre de workers Sidekiq pour gérer cette charge.)
Je pourrais peut-être arrêter le service Unicorn jusqu’à la fin de l’importation, mais cela ne fait que décaler la charge à un moment ultérieur. Il semble que le traitement doive être effectué d’une manière ou d’une autre.
et vous êtes des gens intelligents.