Главная Windows, Без рубрики, Новое Сравнение производительности SMBv1 и SMBv2
  • Сравнение производительности SMBv1 и SMBv2

    В продолжение сравнительного анализа протоколов разных эпох, а именно SMB v1 и SMB v2, было решено более подробно снять статистику производительности сетевого взаимодействия. В данном случае нас будет интересовать скорость передачи данных в разных средах. Для того, что бы разнообразить простое копирование, будем брать файлы разного размера и разное количество файлов для одного размера. Так же будем использовать разные среды и скорости передачи данных (Ethernet 100/1000/1000мбит/с и Wi-Fi 54 мбит/с).

    Сначала давайте посмотрим на испытательный стенд. Для этого были взят сервер MS Windows 2008R2 с установленной ролью Hyper-V и на нем развернуты “виртуальные” сервера с операционными системами MS Windows 2003/2008R2. На виртуальный сервер выделялось по 2 ядра и по 1гб оперативной памяти. В качестве клиентской машины использовалась MS Windows 7, установленной на ноутбуке. Таким образом мы перекрываем почти всю нынешнею линейку операционных систем от Microsoft.

    Как проводились тестирования

    Прежде всего давайте взглянем на инфраструктуру.

    topology

    Итак для тестирования на разных скоростях и средах применялись следующие связки:

    1. Для проверки скорости по Wi-Fi 54мбит/с и Ethernet 100мбит/с использовалась передача данных с ноутбука Windows 7 на серверные операционные системы Windows 2003/2008R2
    2. Для проверки скорости в 1гбит/с использовалась передача данных с Hyper-V на Windows 2003/2008R2, которые соединены виртуальным сетевым адаптером.

    Проверить на других скоростях, а именно на 10 мбит/с и 10 гбит/с, у меня нет желания и возможности. В первом случае сейчас это уже раритет, а во втором у меня нет под рукой подходящей СХД, которая могла бы загрузить канал в 10 гбит/с.

    Каждое копирование данных запускалось 3 раза, на их основе рассчитывалось среднее значение. После чего по этим данным строились графики.

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

    1. 1 мб
    2. 2 мб
    3. 4 мб
    4. 8 мб
    5. 16 мб
    6. 32 мб
    7. 64 мб
    8. 128 мб
    9. 256 мб
    10. 500 мб
    11. 1000 мб

    Так же был предусмотрен тест сравнение быстрого переваривания нескольких файлов одного размера. Я выбрал размер папки в 30 мб, которая “забивалась” данными разного размера:

    1. По 100 кб
    2. По 200 кб
    3. По 500 кб
    4. По 1 мб
    5. По 2 мб
    6. По 4 мб
    7. По 8 мб

    В итоге получали папку размером в 30 мб, но забитой сотней файлов по 100кб или по 200 кб. Чем больше был размер одиночного файла, тем меньшее количество таких файлов требовалось, что бы “забить” данную папку.

    Ну что ж приступим к анализу данных.

    Тестирование на хороших каналах.

    Под хорошими каналами имеется в виду, каналы со стабильной латентностью, без разрывов, без ошибок при передачи данных. К примеру, команда ping будет такой:

    Reply from 192.168.1.103: bytes=32 time<1ms TTL=128
    Reply from 192.168.1.103: bytes=32 time<1ms TTL=128
    Reply from 192.168.1.103: bytes=32 time<1ms TTL=128

    Исключением является только канал связи Wi-Fi. Хоть соединение у него относительно стабильное, но внешняя среда может значительно менять качество принимаемого сигнала. А это может сказывается на скорости передачи данных и прочих параметрах. Для исключения фактора внешней среды необходимо проводить тестирования там, где нет других точек доступа, а так же прочих электромагнитных источников.

    По этой причине относиться к графикам, основанным на данных при передачи по Wi-Fi, следует скептически. Для исключения данного фактора, тесты по Wi-Fi производились в двойном размере, что позволяет получить более стабильные данные.

    WiFi 54мбит/с, Avg Time: 1 ms

    Как уже и говорилось раньше, для такого теста я использовал связку Windows 7 на ноутбуке и Windows 2003/2008R2 на Hyper-V.

    Давайте посмотрим график скорости передачи данных:
    WiFi_speed
    По оси X: размер данных. По оси Y: скорость в мб/с. Чем больше скорость, тем лучше.

    Итак видно, что SMB протокол второй версии чуть быстрее, чем первой. Но разница не уловима на глаз и составляет минимальный разрыв. Так же, возможно, вы заметили, что SMB v2 иногда просаживается по скорости даже ниже первого. Скорее всего это связано с нестабильной связью до точки доступа (Access Point).

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

    Ethernet 100 мбит/с, Avg Time: 1 ms

    В данном случае использовалась передача данных по “проводной” сети с ноутбука, с установленной ОС Windows 7, на виртуальные сервера, под управление MS Windows 2003/2008R2.

    Давайте посмотрим график скорости передачи данных:
    100mbit
    По оси X: размер данных. По оси Y: скорость в мб/с. Чем больше скорость, тем лучше.

    Разница по скорости передачи данных между протоколами SMB v1 и SMB v2 существует. Но не такая большая, как хотелось бы. Преимущество второй версии SMB составляет порядка 5-20%, по сравнению с первой версией. Скорость обработки мелких файлов значительно падает, но и тут SMB v2 обгоняет первую версию.

    Ethernet 1 гбит/с, Avg Time: 1 ms

    На данном тесте данные копировались с сервера Hyper-V R2 (т.е. с хостового сервера) на сервера под управлением Windows 2003/2008R2 (т.е. на виртуальные сервера). Таким образом все происходило в пределах одной физической машины. Соединение происходит через виртуальный сетевой адаптер, создаваемый в виртуальном свитче Hyper-V.

    Давайте посмотрим график скорости передачи данных:
    1gbits
    По оси X: размер данных. По оси Y: скорость в мб/с. Чем больше скорость, тем лучше.

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

    Скорости по обработки одного файла значительно разнятся, достигая 10-20%. Что уже довольно приличный прирост скорости. На наборе мелких файлов, это уже не так заметно. Причина тому: много служебной информации, т.к. много файлов. Но все же разница есть и по мере увеличения размера одиночного файла, входящего в состав – она увеличивается.

    Тестирование на плохих каналах

    Если вы читали предыдущею мою статью про SMB, то возможно помните, что в SMB v2 есть новая фишка позволяющая быстрей передавать данные на медленных каналах. Медленный в плане латентности, т.е. задержек.

    Для подтверждения данной технологии – будем использовать каналы связи с большой задержкой.Если раньше подключение было таким:
    Reply from 192.168.1.103: bytes=32 time<1ms TTL=128
    Reply from 192.168.1.103: bytes=32 time<1ms TTL=128
    Reply from 192.168.1.103: bytes=32 time<1ms TTL=128

    То теперь вот такое:
    Reply from 192.168.1.103: bytes=32 time=171ms TTL=128
    Reply from 192.168.1.103: bytes=32 time=312ms TTL=128
    Reply from 192.168.1.103: bytes=32 time=93ms TTL=128

    Среднее время задержки составляет порядка 200 ms. Пусть это и будет значением, которое описывает нашу текущею среду.

    WiFi 54мбит/с, Avg Time: 200 ms

    Этот тест аналогичен тесту из первой части. Для такого теста я использовал связку Windows 7 на ноутбуке и Windows 2003/2008R2 на Hyper-V.

    Давайте посмотрим график скорости передачи данных:
    WiFi_speed poor
    По оси X: размер данных. По оси Y: скорость в мб/с. Чем больше скорость, тем лучше.

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

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

    Ethernet 100 мбит/с, Avg Time: 200 ms

    Этот тест аналогичен тесту из первой части. Использовал связку Windows 7 на ноутбуке и Windows 2003/2008R2 на Hyper-V.

    Давайте посмотрим график скорости передачи данных:
    100mbit poor
    По оси X: размер данных. По оси Y: скорость в мб/с. Чем больше скорость, тем лучше.

    Разброс скоростей просто огромен! SMB v2 в тестах до 7-ми раз превосходит SMB v1. Чем больше размер одиночного файла, тем больше скорость, на SMB v2 различия намного нагляднее. На одиночных файлах замечается точно такая же тенденция к увеличению скорости.

    Можно с уверенностью сказать, что в данном случае SMB v2 работает намного лучше, чем его первая версия.

    Ethernet 1 гбит/с, Avg Time: 200 ms

    Этот тест аналогичен тесту из первой части. На данном тесте данные копировались с сервера Hyper-V R2 (т.е. с хостового сервера) на сервера под управлением Windows 2003/2008R2 (т.е. на виртуальные сервера). Таким образом все происходило в пределах одной физической машины.

    Давайте посмотрим график скорости передачи данных:
    1gbits poor
    По оси X: размер данных. По оси Y: скорость в мб/с. Чем больше скорость, тем лучше.

    SMB v2 разрывает просто в клочья SMB v1 на таких скоростях и на плохом канале. Разница стабильна и с увеличением размера файла увеличивается. Поведение на большом количестве мелких файлов как обычно: резкий провал по скорости, но с увеличением размера фрагмента скорость повышается. Это повышение хорошо видно на примере SMB v2.

    Заключение

    На примере моих тестов, можно сделать вывод, что SMB v2 будет побыстрей SMB v1. Особенно это заметно на каналах с быстрым соединением, т.е. на каналах  1 гбит/с и выше. На каналах связи по медленнее разница так же существует, но она заметна не так сильно.

    Показательные тесты на каналах с плохой связью выявили, что  SMB v2 переваривает их значительно лучше, я бы сказал, в разы лучше, чем SMB первой версии. У SMB v2 на таких каналах скорость довольно сильно отличалась, в зависимости от размера файла, который надо передать. У SMB v1 же скорость почти постоянная на любом размере файлов.

    Размер файла, передаваемого по протоколу SMB сильно влияет на скорость, вне зависимости от его версии. Чем больше размер файла, тем большая скорость может развиться при его передачи. Причина тому: обе версии протокола “не любят” большое количество мелких файлов, обработка их сильно сказывается на производительности сетевого взаимодействия, т.е. на скорости. Причина тому, большое количество служебной информации.

    Для любителей сухой статистики: данные моих тестов в формате MS Excel.

    Баканов Денис

    MCSE+S; MCITP EA

    Оригинал статьи

Комментарии

  1. Хорошая работа на плохих каналах это не заслуга SMBv2, а заслуга нового стека TCP/IP, в котором реализован ряд RFC – фичей в TCP/IP, которые помогают работе на плохих каналах и на радио каналах.

  2. Мне кажется что тут заслуга технологии smb “pipelining”, о которой я писал в прошлый раз.

  3. Одно не понял. В первой статье говорится, что на большом файле разница незначительна, а в этой обратное. Чему верить?

  4. Илья, если посмотреть внимательно, то в первой статье упоминалось про 100 мбит/с и WiFi. И только на “хороших каналах”

    Так вот. Если сравнить второй график в этой статье с тем графиком при большом файле, то можно заметить, что разница так и осталась незначительной.

    В первой статье я не тестировал на 1гбит/с, где была достигнута максимальная разница для “хороших каналов”.

    п.с. я про этот график: http://www.inadmin.ru/wp-content/uploads/2010/06/Speed_one_thumb.png

  5. Согласен с Ильей, мен кажется тут больше работает новый стек. Как я и писал в прошлых коментах, на стабильных каналах новый стек присылает одно подтверждение на несколько пакетов. А вот работа на “плохих” каналах для меня стала неожиданностью 🙂
    Спасибо за тесты.

  6. Для меня тоже некторые данные стали открытием 🙂