Почему многопоточная передача файлов повышает производительность?

RichCopy, лучший инструмент, отличный от robocopy-with-GUI, от Microsoft, по-видимому, является лучшим инструментом для копирования файлов. Одна из его главных особенностей, освещенная в статье TechNet, представляющей инструмент, заключается в том, что она копирует несколько файлов параллельно. В настройках по умолчанию одновременно копируются три файла, которые вы можете увидеть в графическом интерфейсе: [Прогресс: xx% файла A, yy% от файла B,...]. Есть много blog записи вокруг хвалить этот инструмент и утверждая, что это ускоряет процесс копирования.

Мой вопрос: Почему этот метод повышает производительность? Насколько я знаю, при копировании файлов на современных компьютерных системах жесткий диск является узким местом, а не ЦП или сетью. Мое предположение заключалось в том, что копирование нескольких файлов сразу делает весь процесс медленнее, так как HDD должен перескакивать между разными файлами, а не просто последовательно передавать один файл. Поскольку RichCopy работает быстрее, в моих предположениях должна быть какая-то ошибка...

Ответ 1

Инструмент использует усовершенствования аппаратного обеспечения, которые могут оптимизировать несколько запросов на чтение и запись намного лучше.

При копировании одного файла за раз оборудование не будет знать, что блок данных, который в настоящее время проходит под заголовком чтения (или рядом), будет необходим для подзадачного чтения, поскольку программное обеспечение не поставило в очередь этот запрос еще.

В настоящее время одна копия файла не является очень сложной задачей для современных дисковых подсистем. Благодаря тому, что эти аппаратные системы работают более оперативно, инструмент использует улучшенные функции оптимизации.

Ответ 2

Наивное приложение "копировать несколько файлов" скопирует один файл, а затем дождитесь его завершения до копирования следующего.

Это означает, что отдельный файл НЕ МОЖЕТ копироваться быстрее, чем задержка в сети, даже если он пуст (0 байтов). Поскольку он, вероятно, выполняет несколько вызовов файлового сервера (open, write, close), это может быть несколько задержек.

Чтобы эффективно копировать файлы, вы хотите иметь сервер и клиент, которые используют протокол протокола, который имеет конвейерную обработку; это означает, что клиент НЕ ждет, пока первый файл будет сохранен перед отправкой следующего, и действительно, несколько или несколько файлов могут быть "на проводе" сразу.

Конечно, для этого потребуется настраиваемый сервер, а не сервер SMB (или аналогичный). Например, rsync делает это и очень хорошо копирует большое количество файлов, несмотря на однопоточность.

Поэтому я предполагаю, что многопоточность помогает, потому что это связано с тем, что сервер не поддерживает конвейерную обработку на одном сеансе.

Однопоточная реализация, которая использовала разумный протокол, была бы лучше всего, на мой взгляд.

Ответ 3

Это сетевой инструмент, поэтому узким местом является сеть, а не жесткий диск. До (низкой) точки вы можете получить большую пропускную способность из TCP-канала, используя несколько подключений параллельно. Это (а) распараллеливает рукопожатия TCP; (б) может лучше использовать продукт задержки полосы пропускания, если он высок; и (c) не делает одно произвольно медленное соединение критическим путем, если по какой-либо причине он встречает высокий коэффициент RTT или отказа.

Другой способ сделать (b) - использовать огромный буфер приема сокета TCP, но это не всегда удобно.

Некоторые другие ответы на HDD неверны. Практически любой жесткий диск будет делать некоторые операции чтения вперед в предположении о последовательном доступе, и любой интеллектуальный кэш ОС также будет делать это.

Ответ 4

Мои соображения состоят в том, что hdd read write heads проводят большую часть своего времени бездействия и ждут, когда будет создан правильный блок памяти на диске, чем больше копируется память, тем меньше времени в режиме ожидания, и большинство современных планировщиков дисков должны принимать уход за прыжками (для небольшого количества файлов/фрагментов)

Ответ 5

Насколько я знаю, при копировании файлов на современных компьютерных системах жесткий диск является узким местом, а не ЦП или сетью.

Я думаю, что эти предположения слишком упрощены.

Во-первых, в то время как локальные сети работают со скоростью 100 Мбит /1 Гбит. Сети с длинной сетью имеют максимальную скорость передачи данных, которая меньше максимальной скорости самой медленной линии.

Во-вторых, эффективная пропускная способность потока TCP/IP через Интернет часто определяется временем, затрачиваемым на сообщения и подтверждения в оба конца. Например, у меня есть ссылка 8 + Mbit, но скорость передачи данных при загрузке редко превышает 1-2 Мбит в секунду при загрузке из США. Поэтому, если вы можете запускать несколько потоков параллельно, один поток может ждать подтверждения, а другой - перекачки пакетов. (Но если вы попытаетесь отправить слишком много, вы начнете получать перегрузки, тайм-ауты, отсрочку и снизить общие скорости передачи.)

Наконец, операционные системы хорошо выполняют различные задачи ввода-вывода параллельно с другой работой. Если вы загружаете 2 или более файлов параллельно, O/S может считывать/обрабатывать сетевые пакеты для одной загрузки и записи на диск для другого... в то же время.

Ответ 6

На больших расстояниях сети могут писать намного быстрее, чем они могут читать. При многопоточности, наличие дополнительных "считывателей" означает, что данные могут передаваться более эффективно и не увязнуть в буферах.