¿Funciona la descompresión en paralelo?

En una publicación anterior , tuve la oportunidad de escribir una utilidad de descompresión que usa archivos descomprimidos en paralelo, sobre la base de que Rust hace que esto sea seguro para intentarlo.

Estos son algunos resultados de rendimiento.

El caso de uso que me interesa es descomprimir las compilaciones de Chromium ASAN que se pueden obtener desde aquí . Para estas pruebas, elegí una compilación en particular, que tiene 3.845.117.901 bytes.

ripunzipahora admite dos modos: ripunzip file <filename>, y ripunzip uri <URI>. El primero simplemente descomprime un archivo. Este último utiliza múltiples solicitudes de rango HTTP para realizar la descarga y descomprimir en paralelo. (Las solicitudes de rango son necesarias debido a la estructura de un archivo zip: necesita leer la información del directorio distribuida por todo el archivo antes de que pueda comenzar a descomprimir realmente el contenido).

(Usando ripunzipSHA ca71fa12e7510b9d48b55ccd6a9dfe051291ca42. Estos resultados no se han repetido para que sean estadísticamente válidos porque no quiero poner demasiada carga en el servidor HTTP de origen. Hay algunos cargo criterionpuntos de referencia oficiales en el proyecto, pero no representan adecuadamente la red del mundo real condiciones).

¡Hay algunos resultados interesantes aquí!

Primero, las buenas noticias sobre la descompresión de archivos: descomprimir este archivo zip en una máquina virtual Linux rápida lleva 9 segundos , a diferencia de la descompresión, que tarda 94 segundos. En una máquina virtual de Windows, son 52 segundos en comparación con los 165 segundos de 7z.

Sin embargo, esta mejora no es universal. En una máquina virtual Linux lenta, ripunzipen realidad es más lento. No puedo explicar esto por completo: parece tener algo que ver con el backend de almacenamiento del sistema de VM que lucha por hacer frente a muchas solicitudes paralelas. ¿Quizás son los cabezales de disco duro físicos reales que buscan algún lugar en la nube? (Guau. No anticipé tener que hacer que esta herramienta funcionara de manera eficiente para trozos de metal antiguo). No estoy seguro de que esta sea la explicación, pero parece tener algo que ver con velocidades de escritura lentas.

Al descomprimir directamente desde un URI, generalmente vemos que ripunzipparece tener un ancho de banda limitado. ¡ En el buen sentido! Completamos la descompresión en tan solo unos segundos más de lo que hubiera tomado descargar el archivo zip en primer lugar usando curl, por lo que efectivamente obtenemos la descompresión "gratis". Esto no se aplica en Windows, posiblemente porque usé Chrome para descargar el archivo zip ( curlno estaba disponible). Pero, la velocidad de descompresión es mucho más rápida en esta máquina con Windows que sigue siendo ventajosa.

Un punto particularmente interesante es que ripunzip uries más rápido que ripunzip fileen la VM Linux lenta... Supongo que buscar cabezas de disco entre el archivo zip y los archivos descomprimidos es realmente muy lento, mientras que leer desde un servidor HTTP remoto es realmente más rápido (!)

¿Qué significa esto para los cromies que reproducen errores de seguridad? Bueno, necesito empaquetar la herramienta y hacer que esté disponible en todos nuestros entornos de prueba, pero en general significa uno o dos minutos guardados por compilación de Chromium que tenemos que descargar... (¿siempre que esté usando un SSD?) Eso en realidad importa cuando tenemos que descargar varias compilaciones, varias veces al día. Será interesante ver si estos resultados se amplían a las compilaciones UBSAN de 36 GB, y si esta herramienta también puede hacer que algunos de nuestros sistemas automatizados sean más rápidos. (Creo que averiguaré bastante rápido si esos sistemas están respaldados por SSD o discos duros...)

Puedes probar todo esto con cargo install ripunzip.