Как максимально использовать возможности стеков протоколов TCP/IP

Технический обзор

Сейчас, когда скорости доступа в Internet растут, может оказаться, что скорость, с которой вы путешествуете в киберпространстве, в ближайшем будущем будет определяться выбранным вами стеком TCP/IP.

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

Для тестирования в центре Ziff-Davis Benchmark Operation (Релей, шт. Сев. Каролина) мы использовали ServerBench 3.0, новейшую программу из комплекта тестов Ziff-Davis для систем клиент - сервер. В клиентскую и управляющую программы ServerBench 3.0 встроены возможности работы с любым стеком протоколов TCP/IP, соответствующим спецификации Winsock 1.1.

Мы тестировали SuperTCP for Windows корпорации Frontier Technologies, OnNet 2.0 for Windows и OnNet32 for Windows 95 and Windows NT фирмы FTP Software, Microsoft TCP/IP-32b for Windows for Workgroups и Microsoft TCP/IP for Windows 95, Trumpet 2.0b for Windows фирмы Trumpet Software International Ptu и Chameleon for Windows фирмы NetManage. (OnNet 2.0 фирмы FTP Software тестировался как под Windows 3.11, так и под Windows for Workgroups.)

Как мы проводили тестирование

Мы установили изолированную тестовую ЛВС, включающую в качестве клиента 66 МГц ПК Compaq DeskPro 486 корпорации Compaq Computer с 16 Мб ОЗУ и Ethernet-адаптером NE2000 фирм Novell/Anthem. В ходе всех тестов на клиенте был запущен пакетный драйвер сетевого адаптера реального режима.

Управляющая машина ServerBench представляла собой ПК Dell 433/M корпорации Dell Computer с 32 Мб ОЗУ, на котором был установлен Ethernet-адаптер Novell/Anthem NE2000.

Роль сервера выполнял компьютер Dell Dimension XPS P100c на основе 100 МГц Pentium с 32 Мб ОЗУ и Ethernet-адаптером 3C5X9 фирмы 3Com.

Тестовые машины были соединены с помощью 10 Мбит/с концентратора 10BaseT Accton EtherHub. На сервере использовался Windows NT 3.51 Service Pack #4.

Для каждого стека TCP/IP мы выполняли четыре теста: стандартный тест сети ServerBench, дополнительный специальный сетевой тест и два теста с использованием ПО третьих фирм.

Результаты по тесту сети ServerBench отличаются от остальных, потому что ServerBench оптимизирован для тестирования производительности сервера. Мы модифицировали стандартный сетевой тест ServerBench, чтобы следить за производительностью клиента.

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

В качестве ПО третьих фирм мы использовали WS_FTP, бесплатную FTP-программу для Windows, и Netscape Navigator 2.0 for Windows (16-разрядная версия), а также Netscape Navigator 2.0 for Windows 95 (32-разрядная версия) корпорации Netscape Communications.

Используя это ПО, мы смоделировали тестовую ситуацию: подключение к серверу в качестве FTP-клиента, загрузка файла длиной 12 Мб, фиксация времени, затраченного на транзакцию.

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

Результаты тестирования

При тестировании под Windows 3.1 впереди были OnNet 2.0 и Trumpet 2.0b, а SuperTCP и Chameleon оказались самыми медленными.

В тестах под Windows for Workgroups мы обнаружили небольшое преимущество Microsoft TCP/IP-32b for Windows for Workgroups по сравнению с FTP OnNet 2.0. Этот порядок сохранился и в тестах под Windows 95, где Microsoft TCP/IP for Windows 95 превзошел по производительности FTP OnNet32. (В тестах под Windows 95 мы запускали клиентское ПО на управляющей машине, поскольку на ней уже работала ОС Windows 95. Следовательно, результаты тестов под Windows 95 не следует сравнивать с результатами для двух других операционных систем.)

Изобилие аномалий

В ходе тестирования мы обнаружили аномалию, проявляющуюся при использовании Microsoft TCP/IP-32b for Windows for Workgroups и запуске теста сети ServerBench. Если тест занимал менее 1 мин, результаты были превосходны. Но, когда мы запускали его на более длительное время, параметры производительности постепенно ухудшались.

Чтобы выяснить источник проблемы, мы подключили к тестовой сети сетевой анализатор и обнаружили, что стеку Microsoft TCP/IP-32b требовалось все больше и больше времени, чтобы подтвердить получение данных, которые сервер отправил клиенту. После того как тест работал в течение 5 мин, мы зафиксировали, что для подтверждения потребовалось около 0,4 с.

Мы наблюдали эту аномалию на нескольких машинах с различными сетевыми картами. Тем не менее, когда другие стеки TCP/IP также работали под Windows for Workgroups, более низкие, чем обычно, результаты не наблюдались. Мы полагаем, что проблема связана с динамической библиотекой Winsock, которую каждый поставщик стека разрабатывает независимо. Winsock.dll  -  это ключевой программный компонент, с которым взаимодействует каждое приложение, удовлетворяющее спецификации Winsock.

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

(т. е. более 1 мин). Типичный пользователь (использующий стек, скорее всего, для прогулок по Internet) не столкнется с падением производительности.

Другая встретившаяся проблема была связана со стеком OnNet 2.0 for Windows 95 фирмы FTP Software. Стек иногда терял данные, особенно если сервер быстро отвечал на запрос о транзакции. После консультации со службой технической поддержки FTP Software мы решили проблему, загрузив более свежую версию ее библиотеки winsock.dll.

Мы обнаружили, что сходные ситуации весьма часто встречаются при тестировании стеков TCP/IP в условиях высокой нагрузки и часто проблема вызывается устаревшим компонентом TCP/IP или драйвером сетевого адаптера. Следовательно, чтобы получить максимальную производительность стека TCP/IP, и сетевым администраторам, и пользователям важно заботиться о том, чтобы использовать последние версии ПО.

Как максимально использовать стек

Результаты наших тестов менялись при простом изменении значения параметра TCP Receive Window (окно приема TCP). Этот параметр задает максимальный объем переданных данных, получение которых еще не подтверждено. При его превышении отправитель прекращает передачу данных и ожидает подтверждения.

Мы обнаружили, что значение этого параметра по умолчанию для большинства стеков TCP/IP равно 8 Кб. Поэтому, чтобы выравнять условия, мы при тестировании установили значение TCP Receive Window, равное 8 Кб, для всех семи стеков.

В качестве эксперимента мы увеличили его значение для всех стеков (кроме продукта Chameleon, который не допускает изменения значения TCP Receive Window) до 20 Кб и вновь выполнили тест сети ServerBench.

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

Это означает, что производительность стека TCP/IP можно настраивать. Для получения максимальной производительности, возможно, нужно изменить значения параметров в зависимости от используемых приложений. Метод проб и ошибок, хотя он и не слишком научен, может оказаться лучшим выходом, поскольку возможности настройки параметров отличаются в разных продуктах. Чтобы максимально использовать возможности стека TCP/IP, следует позвонить в группу технической поддержки, объяснить, как стек будет использоваться, и попросить рекомендации по улучшению производительности.

Джефф Дауни, Дебби Уилмшен