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.

[Mrgaton]

después de investigar un poco lo único que haría es subir la lgwin y ya y dejar el nivel a 11 ya que el mode no afecta en nada en nivel 11.

[inetol]

@Mrgaton He hecho un par de pruebas (ignorar gzip) y he sacado esto, creo que el level predeterminado de brotli en Zlib es 7..:

string aleatorio

Con un string totalmente aleatorio que sería comparable a subir una imagen, el margen entre level 1 y 11 es prácticamente nulo:

string lorem ipsum

Con ~1000 párrafos de lorem ipsum hay más margen entre uno y otro, pero muy por debajo para que prefiriera un level superior a 1 con el incremento exponencial de latencia:

Igualmente no sé por qué hay tan poco margen con Gzip, esto también aplica a DEFLATE que no parece comprimir los buffers correctamente (también algunos levels más altos de brotli comprimen peor que los anteriores ?)

[Mrgaton]

un string aleatorio es normal que no comprima prácticamente nada ningún algoritmo, se basan en buscar ocurrencias iguales para eliminarlas y ahorrar espacio, yo el mínimo nivel que le pondría de brotli seria 9 ya que es el que mejor compresión tiene sin que el tiempo sea abismal pero tampoco me importaría que fuera 11 ya que prefiero esperar 20 milisegundos que se comprima mejor a que ocupe mas espacio.

[inetol]

Al final se ha decidido hacer configurable el level de brotli desde él .env, pero de forma predeterminada se fijará a 1