A descompactação paralela funciona?

Em uma postagem anterior , tive a oportunidade de escrever um utilitário de descompactação que usa arquivos de descompactação em paralelo, com base no fato de que Rust torna essa tentativa segura.

Aqui estão alguns resultados de desempenho.

O caso de uso que me interessa é descompactar as compilações do Chromium ASAN que podem ser obtidas aqui . Para esses testes, escolhi uma compilação específica, que tem 3.845.117.901 bytes.

ripunzipagora suporta dois modos: ripunzip file <filename>, e ripunzip uri <URI>. O primeiro apenas descompacta um arquivo. Este último usa várias solicitações de intervalo HTTP para realizar o download e descompactar em paralelo. (As solicitações de intervalo são necessárias devido à estrutura de um arquivo zip - ele precisa ler as informações do diretório espalhadas por todo o arquivo antes de começar a descompactar o conteúdo).

(usando ripunzipSHA ca71fa12e7510b9d48b55ccd6a9dfe051291ca42. Esses resultados não foram repetidos para serem estatisticamente válidos porque não quero colocar muita carga no servidor HTTP de origem. Existem alguns cargo criterionbenchmarks oficiais no projeto, mas eles não representam adequadamente a rede do mundo real condições).

Há alguns resultados interessantes aqui!

Primeiro, as boas notícias sobre a descompactação de arquivos: descompactar este arquivo zip em uma VM Linux rápida leva 9 segundos , ao contrário de descompactar, que leva 94 segundos. Em uma VM do Windows, são 52 segundos em vez de 165 segundos para 7z.

No entanto, esta melhoria não é universal. Em uma VM Linux lenta, ripunzipé realmente mais lento. Não consigo explicar isso completamente - parece ter algo a ver com o back-end de armazenamento do sistema VM lutando para lidar com muitas solicitações paralelas - talvez sejam cabeças de disco rígido físicas reais procurando em algum lugar na nuvem? (Uau. Não previ ter que fazer essa ferramenta funcionar com eficiência para pedaços de metal antiquado.) Não tenho certeza se essa é a explicação, mas parece ter algo a ver com velocidades de gravação lentas.

Ao descompactar diretamente de um URI, geralmente vemos que ripunzipparece ser limitado pela largura de banda. No bom sentido! Concluímos a descompactação em apenas alguns segundos a mais do que levaria para baixar o arquivo zip em primeiro lugar usando curl, de forma eficaz, obtemos a descompactação “de graça”. Isso não se aplica ao Windows, possivelmente porque usei o Chrome para baixar o arquivo zip ( curlnão estava disponível). Mas, a velocidade de descompactação é muito mais rápida nesta máquina Windows que ainda é vantajosa.

Um ponto particularmente interessante é que ripunzip urié mais rápido do que ripunzip filena lenta VM do Linux… Acho que procurar cabeças de disco entre o arquivo zip e os arquivos descompactados é realmente muito lento, enquanto a leitura de um servidor HTTP remoto é realmente mais rápida (!)

O que isso significa para os Chromies que reproduzem bugs de segurança? Bem, preciso empacotar a ferramenta e disponibilizá-la em todos os nossos ambientes de teste, mas, no geral, isso significa um ou dois minutos economizados por compilação do Chromium que temos que baixar… (desde que você esteja usando um SSD?) Isso realmente importa quando temos que baixar várias compilações, várias vezes ao dia. Será interessante ver se esses resultados aumentam para as compilações UBSAN de 36 GB e se essa ferramenta também pode tornar alguns de nossos sistemas automatizados mais rápidos. (Acho que vou descobrir rapidamente se esses sistemas são suportados por SSDs ou discos rígidos…)

Você pode tentar tudo isso com cargo install ripunzip.