Почему многопоточная передача файлов повышает производительность?
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
На больших расстояниях сети могут писать намного быстрее, чем они могут читать. При многопоточности, наличие дополнительных "считывателей" означает, что данные могут передаваться более эффективно и не увязнуть в буферах.