tanenbaum_seti_all.pages (525408), страница 170
Текст из файла (страница 170)
Датсе мы перечислим некоторые из них. Следует тщательно избегать подобных ошибок при любых |юпытках измерить производительность сети. Убедитесь, что выборка достаточно велика Не следует ограничиваться единственным измерением какого-нибудь параметра — например, времени, необходимого для передачи одного ТРП(1-модуля. Повторите измерение, скажем, миллион раз и вычислите среднее значение, Чем больше будет выборка, тем выше окажется точность оценки среднего значения и его среднеквадратичного отклонения. Погрешность может быть вычислена при помощи стандартных формул статистики. Убедитесь, что выборка является репрезентативной Следует повторить всю последовательность миллиона измерений параметров в различное время суток и в разные дни недели, чтобы заметить влияние различной загруженности системы на измеряемые параметры. Так, измерение перегрузки вряд ли принесет пользу, если эти измерения производить, когда перегрузки нет.
Иногда результаты могут показаться на первый взгляд странными, как, например, наличие серьезных заторов в сети в 10, 11, 13 и 14 часов, но их отсутствие в полдень (когда все пользователи обедают). Используя часы с грубой шкалой, будьте внимательны Компьютерные часы работают, добавляя единицу к некоему счетчику через равные интервалы времени. Например, миллисекундный таймер увеличивает на единицу значение счетчика раз в 1 мс. Применение такого таймера для измерения длительности события, занимающего менее 1 мс, возможно, но требует осторожности. Например, чтобы измерить время, необходимое для передачи одного ТРВ()- модуля, следует считывать показания системных часов (скажем, в миллисекундах) при входе в программу транспортного уровня и выходе нз нее.
Если время, требуемое для передачи одного ТРГН1-модуля, равно 300 мкс, то измеряемая величина будет равна либо 0, либо 1 мс. Однако если повторить измерения миллион раз, сложить все значения и разделить на миллион, то полученное среднее значение будет отличаться от истинного значения менее чем на 1 мкс. Убедитесь, что во время ваших тестов не происходит ничего неожиданного Если проводить измерения в университетской системе в день сдачи главного лабораторного проекта, то полученные результаты могут сильно отличаться от результатов измерений, произведенных на следующий день.
Аналогично, если в то Вопросы производительности бэа время, когда вы производите тестирование сети, какой-нибудь исследователь решит устроить в сети видеоконференцию, вы также можете получить искаженные результаты. Лучше всего запускать тесты на пустой системе, создавая всю нагрузку самому. Хотя и в этом случае можно ошибиться. Вы можете предполагать, что никто не пользуется сетью в 3 часа ночи, но может оказаться, что именно в это время программа автоматического резервного копирования начинает свою работу по архивации всех жестких дисков на магнитную ленту.
Кроме того, именно в это время пользователи, находящиеся в другой временной зоне на другой стороне Земного шара, могут создавать довольно сильный трафик, просматривая ваши замечательные веб-страницы. Кэширование может сильно исказить ваши измерения Чтобы измерить время операции по передаче файла, самый очевидный путь состоит в том, чтобы открыть большой файл, прочитать его целиком и закрыть, измерив при этом время, затраченное на всю последовательность операций. Затем можно повторить измерение много раз, чтобы получить точное значение средней величины. Беда заключается в том, что система может, считав файл по сети всего один раз, запомнить его в локальном каше. Таким образом, правильным будет только первое измерение, а при остальных операциях обращения к сети не будет. Результат такого многократного измерения будет бесполезен (если только вы не измеряете производительность кэша).
Часто можно обмануть алгоритм кэширования, просто заставляя переполняться кэш. Например, если размер кэша составляет 10 Мбайт, в тестовый цикл можно включить поочередное открытие, чтение и закрытие двух 10-мегабайтных файлов, пытаясь заставить систему каждый раз читать файлы по сети.
Тем не менее, следует быть уверенным в том, что вы понимаете, как работает алгоритм кэширования. Буферизация пакетов может производить аналогичный эффект. Одна популярная ТСР/1Р-программа измерения производительности славилась тем, что сообщала, что протокол 1Л)Р может достичь производительности, значительно превышаюшей максимально допустимую для данной физической линии. Как зто происходилоу Обращение к ПЭР обычно возврагдает управление сразу, как только сообщение принимается ядром системы и добавляется в очередь на передачу.
При достаточном размере буфера время выполнения 1000 обращений к 1ЛЭР не означает, что за это время все данные были переданы в линию. Большая часть их все еще находится в буфере ядра. Следует хорошо понимать, что измеряется Когда вы измеряете время чтения удаленного файла, результаты ваших измерений зависят от сети, операционной системы клиента и сервера, аппаратного интерфейса сетевых карт, их драйверов и других факторов. Если все делать внимательно, то в конечном итоге вы получите значение времени передачи файла для данной конфигурации. Если вы ставите перел собой цель настроить именно эту конкретную конфигурацию, то беспокоиться не о чем.
Е40 Глава 6. Транспортный уровень Однако если вы проводите сходные измерения па трех различных системах, чтобы выбрать, какую сетевую карту купить, то ваши результаты могут оказаться никуда не годными из-за того, что какой-нибудь сетевой драйвер окажется неудачным и использующим лишь 10 У4 производительности сетевой карты. Будьте осторожны с экстраполяцией результатов Предположим, вы что-нибудь измеряете (например, время ответа удаленного хоста), моделируя нагрузку сети от 0 (простой) до 0,4 (40 У4 мощности), как показано жирной линией на рис.
6.35. Может оказаться соблазнительным линейно экстраполировать полученную кривую (пунктир). Однако в действительности многие параметры в теории массового обслуживания содержат в качестве сомножителя 1/(1 — р), где р — нагрузка, поэтому истинная кривая зависимости будет больше походить на гиперболу, показанную штриховой линией. вэ р о и я Ж2 0,1 0,2 0,3 0,4 0,6 0,6 0,7 0,8 0,9 1,0 Нагрузка Рис. 6.36. Зависимость времени ответа от нагрузки Проектирование производительных систем Измерения и настройки часто позволяют значительно улучшить производительность сети, олнако они никогда пе заменят хорошо разработанного проекта. Плохо спроектированная сеть может быть усовершенствована только до определенного уровня.
Для дальнейшего увеличения ее производительности ее потребуется пе. ределать с нуля. В данном разделе мы рассмотрим несколько эмпирических правил, основанных на опыте работы со многими сетями, Этн правила касаются пе только устройства сети, но и системных аспектов, так как программное обеспечение и операпионные системы часто оказываются важнее, чем маршрутизаторы и интерфейсные Вопросы производительности 641 карты.
Большинство этих идей известны разработчикам сетей уже много лет н передаются из уст в уста от поколения к поколению. Впервые опи были открыто записаны Моголом (Моди!, 1993). Наше повествование во многом пересекается с его книгой. Другим источником по этой жс теме является (Месса!1е, 1993).
Правило 1: скорость центрального процессора важнее скорости сети Длительные экспсрименты показали, что почти во всех сетях накладные расходы операционной системы и протокола составляют основное время задержки сетевой операции. Например, теоретически минимальное время вызова удаленной процедуры (КРС, Кешосе Ргосег!пге Са!!) в сети Етпсгпсг составляет 102 мкс, что соответствует минимальному запросу (64 байта), на который приходит минимальный (64-байтовый) ответ.
На практике значительным достижением считается хотя бы какое-нибудь снижение накладных расходов, возникающих за счет программного обеспечения при вызове удаленной процедуры. Аналогично, при работе с гигабитной линией основная задача заключается в достаточно быстрой псрсдачс битов из буфера пользователя в линию, а также в том, чтобы получатель смог обработать их с той скоростью, с которой они приходят, Короче говоря, удвоснис производительности процессора нередко может привести к почти удвоению пропускной способности канала. Удвоение жс пропускной способности линии часто не дает никакого эффекта, поскольку узким местом обычно являются хосты. Правило 2: уменьшайте число пакетов„ чтобы уменьшить программные накладные расходы Обработка каждого ТР1Н)-модуля подразумевает определенное количество накладных расходов на каждьш модуль (то есть па обработку его заголовка) и определенные затраты при обработке каждого байта (например, при подсчете контрольной суммы).
При отправке 1 млн байт побайтовые затраты времени процессора на обработку не зависят от размера ТРШ)-модуля. Однако при использовании 128-байтовых ТРП!1-модулей затраты на обработку заголовков будут в 32 раза выше, чем для ТРОП-модулей размером 4 Кбайт.
И эти затраты увеличиваются очень быстро. Помимо наклалпых расходов на обработку заголовков ТРОН-модулей, следует рассмотреть накладные расходы нижних уровней. Прибытие каждого пакета вызывает прерывание. В современных К15С-процессорах каждое прерывание нарушает работу процессорного конвейера, снижает эффективность работы кэша, требует изменения контекста управления памятью и сохранения в стеке значительного числа регистров процессора.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
