Работает ли параллельная распаковка?

В предыдущем посте я попытался написать утилиту для распаковки, которая использует распаковку файлов параллельно, на том основании, что Rust делает это безопасным.

Вот некоторые результаты производительности.

Вариант использования, о котором я беспокоюсь, — это распаковка сборок Chromium ASAN, которые можно получить отсюда . Для этих тестов я выбрал одну конкретную сборку размером 3 845 117 901 байт.

ripunzipтеперь поддерживает два режима: ripunzip file <filename>, и ripunzip uri <URI>. Первый просто распаковывает файл. Последний использует несколько запросов диапазона HTTP для параллельной загрузки и распаковки. (Запросы диапазона необходимы из-за структуры zip-файла — ему необходимо прочитать информацию о каталоге, разбросанную по всему файлу, прежде чем он сможет начать фактическую распаковку содержимого).

(с использованием ripunzipSHA ca71fa12e7510b9d48b55ccd6a9dfe051291ca42. Эти результаты не были повторены, чтобы быть статистически достоверными, потому что я не хочу слишком сильно нагружать исходный HTTP-сервер. cargo criterionВ проекте есть несколько официальных тестов, но они неадекватно представляют реальную сеть. условия).

Здесь есть интересные результаты!

Сначала хорошие новости о распаковке файлов: распаковка этого zip-файла на быстрой виртуальной машине Linux занимает 9 секунд , в отличие от распаковки, которая занимает 94 секунды. На виртуальной машине Windows это 52 секунды, а не 165 секунд для 7z.

Однако это улучшение не является универсальным. На медленной виртуальной машине Linux ripunzipна самом деле медленнее. Я не могу полностью объяснить это — похоже, это как-то связано с серверной частью системы хранения виртуальных машин, пытающейся справиться с большим количеством параллельных запросов — возможно, это настоящие головки физических жестких дисков, которые ищут где-то в облаке? (Вау! Я не ожидал, что этот инструмент будет эффективно работать с кусками старомодного металла.) Я не уверен, что это объяснение, но, похоже, это как-то связано с низкой скоростью записи.

При распаковке непосредственно из URI мы обычно видим, что ripunzipпропускная способность ограничена. В хорошем смысле! Мы завершаем разархивирование всего за несколько секунд больше, чем потребовалось бы для загрузки zip-файла в первую очередь с помощью curl, поэтому фактически мы получаем разархивирование «бесплатно». Это не относится к Windows, возможно, потому, что я использовал Chrome для загрузки zip-файла ( curlне был доступен). Но скорость распаковки на этой машине с Windows настолько выше, что это все еще выгодно.

Один особенно интересный момент заключается в том, что это ripunzip uriпроисходит быстрее, чем ripunzip fileна медленной виртуальной машине Linux… Я думаю, поиск головок диска между zip-файлом и разархивированными файлами действительно очень медленный, тогда как чтение с удаленного HTTP-сервера на самом деле быстрее (!)

Что это означает для Chromies, воспроизводящих ошибки безопасности? Что ж, мне нужно упаковать инструмент и сделать его доступным во всех наших тестовых средах, но в целом это означает экономию минуты или двух на каждую сборку Chromium, которую мы должны загрузить… (пока вы используете SSD?) Это на самом деле имеет значение, когда нам приходится скачивать несколько сборок несколько раз в день. Будет интересно посмотреть, будут ли эти результаты масштабироваться до 36-гигабайтных сборок UBSAN, и может ли этот инструмент ускорить некоторые из наших автоматизированных систем. (Думаю, я довольно быстро узнаю, поддерживаются ли эти системы твердотельными накопителями или жесткими дисками…)

Все это можно попробовать с cargo install ripunzip.