Modificar los parametros de compresion de brotli

[Mrgaton]

Estaría bien poder detectar el tipo de documento que se sube para poder especificar en brotli que use 'BROTLI_MODE_TEXT' para mejorar el ratio de compresión, también estaría bien poder incrementar un poco el tamaño del diccionario para tener mejor ratio en documentos grandes.

const options = {
  params: {
    [zlib.constants.BROTLI_PARAM_MODE]: zlib.constants.BROTLI_MODE_TEXT, // 0 = generic, 1 = text, 2 = font (WOFF2)
    [zlib.constants.BROTLI_PARAM_QUALITY]: 11,
    [zlib.constants.BROTLI_PARAM_LGWIN]: 25 // window size of 32 mb
  }
};

[Mrgaton]

No sé si consumiría mucho ir byte por byte en el documento para afirmar si es texto y no otro tipo de binario pero sí no se podría usar el content type sino.

[inetol]

No sabía que la implementación de Brotli en Bun permitiese configurar su compresor, pero sí es así creo que será posible mejorar el uso de CPU en ficheros grandes.

[Mrgaton]

Si cambiamos a zstd esto ya no tiene utilidad,

[inetol]

Pero hasta que no ocurra de momento se queda

[inetol]

Subir el nivel de compresión no sale a cuenta porque te ahorras muy poco casi triplicando el tiempo de compresión, bajándolo si se puede obtener una mejora significativa en el tiempo sin afectar en exceso el tamaño final. (aunque ahora en este caso sea más conveniente usar DEFLATE, hice las pruebas entre ambos de nuevo, pero este último no parece comprimir los binarios adecuadamente)

Modificando otros parámetros (BROTLI_PARAM_MODE) no vi que hiciese nada en strings, ni con datos binarios, por lo que quizás no está implementado (?)

[Mrgaton]

Bajar el nivel de compresión no lo veo a cuenta, ya que la mayoría de archivos que se van a subir serán de pocos kb por no decir pocos bytes y no pasa nada que tarde 100 milisegundos más si a la larga eso ahora más espacio en el disco, que raro que el BROTLI_PARAM_MODE no haga ninguna diferencia probaste si pasa lo mismo en node que en bun?

[inetol]

Al ser los ficheros de Kb quizás algún Mb subir el ratio conlleva un mayor tiempo de CPU, haciendo que la concurrencia sea pobre al estar la mayor parte del proceso de guardado comprimiendo. El almacenamiento es barato a diferencia del procesamiento y por 4kb ahorrados en un documento de 50kb sumándole 60ms extras no lo veo viable, zstd es más eficiente comprimiendo y descomprimiendo manteniendo el ratio a un menor tiempo de CPU (aunque si no está expuesto en Bun o se vincula al binario del sistema entonces ya no hay tanto margen de mejora), pero si fuese un problema sería buscar otras formas de almacenar eficientemente documentos.

Lo de los parámetros de brotli con Node.js no lo probé, pero sí está documentado allí debería de funcionar.