Tedious: Les insertions dans varbinary(max) col avec FILESTREAM ou les lectures à partir de cette colonne prennent 10 secondes

Salut @sammaniamsam ,

Merci de l'avoir signalé. Je pense que cela peut être dû à la façon dont l'analyse des jetons est implémentée dans Tedious, à savoir qu'il y a beaucoup de rappels asynchrones qui occupent beaucoup de mémoire, ce qui devient encore plus vrai lors de l'utilisation de varbinary(max) et peut-être aussi de varchar(max). Nous avons un plan pour refactoriser la façon dont les choses sont implémentées dans Tedious afin d'augmenter les performances à venir dans un avenir proche.

Que pensez-vous @arthurschreiber , @MichaelSun90 ?

Salut @sammaniamsam , je suis juste curieux de savoir quelle version de Tedious utilisez-vous qui cause ce goulot d'étranglement de performance ? #1006

@IanChokS J'utilise "^ 5.0.3"

Ok, après avoir passé au crible tous les problèmes actuellement ouverts, il est clair que le blocage des performances est un problème courant (par exemple, # 879, # 781, # 475, # 467, # 319, # 303). Actuellement, nous avons sur notre feuille de route des éléments tels que la mise en œuvre de la fonctionnalité Always Encrypted, l'amélioration de la validation/conversion des types de données, les fournisseurs d'authentification enfichables et la refactorisation des types de données actuels . Mais sur la base des problèmes soulevés, il semble que ce blocage de performance soit l'obstacle le plus courant auquel les gens sont confrontés lors de l'utilisation fastidieuse. Je discute avec Arthur et l'équipe du travail qui doit être priorisé, donc si vous pensez que l'amélioration des performances est le plus grand changement que vous aimeriez voir, veuillez laisser un like ou commenter vos réflexions sur la façon dont nous devrions aller de l'avant. Tout commentaire serait d'une grande aide! 🙇

WIP pour résoudre les problèmes de performances -> #1037

Descriptif : #1038

Salut @sammaniamsam , nous avons récemment fusionné #1049, #1044, #1037 qui, espérons-le, améliore les performances. Cela vous dérange-t-il si vous exécutez à nouveau votre benchmark par rapport à la dernière branche master et faites-nous savoir si vous constatez une amélioration des performances de votre côté ?

Merci! 🙇

edit : il n'a pas encore été publié sur npm, mais les modifications sont dans la branche principale actuelle

@IanChokS Absolument ! Merci les gars de vous en occuper. J'ai hâte de tester les nouvelles améliorations.

@IanChokS Les résultats sont dans le tableau ci-dessous. Faites moi savoir si vous avez des questions.

Méthode | Version fastidieuse | Nombre de fichiers | Taille | Temps d'exécution (ms)
-- | -- | -- | -- | --
Lire | ^6.3.0 | 1 | 23,33 Mo | 2435.834
Lire | ^6.3.0 | 2 | 46,66 Mo | 5008.435
Lire | ^6.3.0 | 3 | 136,5 Ko | 329.727
Insérer | ^6.3.0 | 2 | 11,9 Mo | 4316.95
Insérer | ^6.3.0 | 4 | 59 Ko | 42.864
Lire | Dernier maître | 1 | 23,33 Mo | 2771.478
Lire | Dernier maître | 2 | 46,66 Mo | 4877.394
Lire | Dernier maître | 3 | 136,5 Ko | 93.575
Insérer | Dernier maître | 2 | 11,9 Mo | 2535.267
Insérer | Dernier maître | 4 | 59 Ko | 43.886

Ça s'annonce bien ! Il correspond à nos résultats pour les inserts. Par exemple, l'utilisation de la mémoire a diminué de moitié.

Nous chercherons certainement à augmenter le temps de lecture également à l'avenir 💪

:tada: Ce problème a été résolu dans la version 8.1.0 :tada:

Le communiqué est disponible sur :

• paquet npm ( @latest dist-tag)
• Version GitHub

Votre bot sémantique :package::rocket: