Назад | Перейти на главную страницу

SMB2 через 1 ГБ PTP Link - задержка 10 мс

Может быть, я ожидаю от SMB2 гораздо большего, чем реально. Вот сценарий.

Сценарий 1:
У меня один файл размером 1ГБ.
Переход с Win7 на сервер A: 10 секунд
Передача с Win7 на сервер B: 18 секунд

Сценарий 2:
У меня есть каталог размером 275 МБ, примерно 2700 файлов.
Переход с Win7 на сервер A: 57 секунд
Передача с Win7 на сервер B: 551 секунда

Действительно ли задержка всего в 10 мс вызывает такой серьезный удар по SMB2 в сценарии 2? Я полагаю, это имело бы смысл, если SMB2 обсуждает каждый отдельный файл (несколько вызовов на файл), помимо времени, необходимого для фактической передачи файла, и это занимает на 10 мс больше в каждую сторону (клиент-> сервер, сервер-> клиент).

Итак, я думаю, все, что я просто спрашиваю, - действительно ли это так же хорошо, как SMB2 проходит через WAN, не пытаясь играть в игры с ускорением SMB2 или другими сторонними уловками?


Обновление1:
Чтобы уточнить: я не спрашиваю, почему много файлов занимает больше времени, чем один большой - я понимаю, что это добавит накладных расходов, несмотря на среду. Я конкретно спрашиваю, достаточно ли 10 мс, чтобы учесть разницу в 10 минут между сервером A и сервером B в сценарии 2. Я понимаю, что нет точного ответа «да» или «нет».

На самом деле просто не знаком с тем, насколько болтливым является SMB2. Я признаю это ЕСТЬ болтать по характеру того, что он делает. Просто интересно, что другие наблюдали в подобных ситуациях. (передача сложной структуры каталогов - более 10 мс 1 ГБ или более ссылка)

Нет, это не проблема SMB2, это проблема передача большого количества маленьких файлов по любому протоколу вопрос. Помимо дополнительных сетевых накладных расходов, вы имеете дело с гораздо большим временем поиска и, по сути, с произвольным чтением вместо последовательных чтений, поэтому операции с диском также намного медленнее. Проверьте себя, например, с помощью USB-накопителя или внешнего жесткого диска. А если хотите, другой сетевой протокол, например FTP.

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

10mc задержка откуда берется? Это ПУТЬ слишком высоко для LAN и ОЧЕНЬ мало для WAN.

И да, это вызывает проблемы - SMB2 довольно болтлив и не оптимизирован для высоких задержек. Многие файлы - это МНОГО операций. Много. Все работают один за другим. В случае сценария 2 вам было бы лучше РАЗДЕЛИТЬ 2700 файлов и запустить несколько операций копирования параллельно. Вот причина, по которой MS сделала SMB3 ..