Tedious: Las inserciones en varbinary(max) col con FILESTREAM o las lecturas de esa columna tardan decenas de segundos

Hola @sammaniamsam ,

Gracias por señalar esto. Creo que esto puede deberse a cómo se implementa el análisis de tokens en Tedious, es decir, hay muchas devoluciones de llamadas asincrónicas que ocupan mucha memoria, lo que se vuelve más cuando se usa varbinary(max) y quizás varchar(max) también. Tenemos un plan para refactorizar cómo se implementan las cosas en Tedious para aumentar el rendimiento en un futuro próximo.

¿Cuáles son sus pensamientos @arthurschreiber , @MichaelSun90 ?

Hola, @sammaniamsam , solo tengo curiosidad por saber qué versión de Tedious estás usando que causa este cuello de botella en el rendimiento. #1006

@IanChokS Estoy usando "^ 5.0.3"

Bien, después de analizar todos los problemas abiertos actualmente, está claro que el bloqueo del rendimiento es un problema común (p. ej., #879, #781, #475, #467, #319, #303). Actualmente, tenemos en nuestra hoja de ruta cosas como la implementación de la función Always Encrypted, la validación/conversión de tipo de datos mejorada , los proveedores de autenticación conectables y la refactorización de los tipos de datos actuales . Pero según los problemas que se plantean, parece que este bloqueo de rendimiento es la barrera más común que enfrentan las personas cuando usan tedioso. Estoy discutiendo con Arthur y el equipo sobre qué trabajo debe priorizarse, por lo que si cree que mejorar el rendimiento es el mayor cambio que le gustaría ver, deje un Me gusta o comente sus pensamientos sobre cómo debemos avanzar. ¡Cualquier comentario sería de gran ayuda! 🙇

WIP para solucionar problemas de rendimiento -> #1037

Descripción: #1038

Hola @sammaniamsam , recientemente fusionamos #1049, #1044, #1037 que esperamos mejore el rendimiento. ¿Le importa si vuelve a ejecutar su punto de referencia con la rama maestra más reciente y nos avisa si ve una mejora en el rendimiento de su parte?

¡Gracias! 🙇

editar: aún no se ha lanzado en npm, pero los cambios están en la rama maestra actual

@IanChokS ¡Absolutamente! Gracias chicos por ocuparse de esto. Estoy deseando probar las nuevas mejoras.

@IanChokS Los resultados están en la siguiente tabla. Hazme saber si tienes alguna pregunta.

Método | Versión tediosa | Número de archivos | Tamaño | Tiempo de ejecución (ms)
-- | -- | -- | -- | --
Leer | ^6.3.0 | 1 | 23,33 MB | 2435.834
Leer | ^6.3.0 | 2 | 46,66 MB | 5008.435
Leer | ^6.3.0 | 3 | 136,5 KB | 329.727
Insertar | ^6.3.0 | 2 | 11,9 MB | 4316.95
Insertar | ^6.3.0 | 4 | 59 KB | 42.864
Leer | Último maestro | 1 | 23,33 MB | 2771.478
Leer | Último maestro | 2 | 46,66 MB | 4877.394
Leer | Último maestro | 3 | 136,5 KB | 93.575
Insertar | Último maestro | 2 | 11,9 MB | 2535.267
Insertar | Último maestro | 4 | 59 KB | 43.886

¡Eso se ve bien! Coincide con nuestros resultados para inserciones. Por ejemplo, el uso de la memoria se ha reducido a la mitad.

Definitivamente buscaremos aumentar el tiempo de lectura también en el futuro 💪

:tada: Este problema se ha resuelto en la versión 8.1.0 :tada:

El lanzamiento está disponible en:

• paquete npm ( @latest dist-tag)
• Lanzamiento de GitHub

Su bot de liberación semántica :paquete::cohete: