Буферирование пакетов может производить аналогичный эффект. Одна популярная TCP/IP-программа измерения производительности славилась тем, что сообщала, что протокол UDP может достичь производительности, значительно превышающей максимально допустимую для данной физической линии. Как это происходило? Обращение к UDP обычно возвращает управление сразу, как только сообщение принимается ядром системы и добавляется в очередь на передачу. При достаточном размере буфера время выполнения 1000 обращений к UDP не означает, что за это время все данные были переданы в линию. Большая часть их все еще находится в буфере ядра.
Следует быть абсолютно уверенным в том, что вы понимаете, как происходит кэширование и буферизация данных.
Убедитесь, что во время ваших тестов не происходит ничего неожиданного
Если в то время, когда вы производите тестирование сети, какой-нибудь исследователь решит устроить в сети видеоконференцию, результаты могут отличаться от результатов, полученных в обычный день. Лучше всего запускать тесты на пустой системе, создавая всю нагрузку самому. Хотя и в этом случае можно ошибиться. Вы можете предполагать, что никто не пользуется сетью в 3 часа ночи, но может оказаться, что именно в это время программа автоматического резервного копирования начинает свою работу по архивации всех жестких дисков на магнитную ленту. Кроме того, именно в это время пользователи, находящиеся в другой временной зоне на другой стороне земного шара, могут создавать довольно сильный трафик, просматривая ваши замечательные веб-страницы.
Особые трудности возникают с беспроводными сетями, так как в этом случае часто бывает трудно отделить сигнал от помех, генерируемых различными источниками. Даже если рядом нет другой активной беспроводной сети, помехи могут возникнуть от того, что кто-то просто начнет готовить попкорн в микроволновой печи, и производительность 802.11 снизится. Поэтому рекомендуется следить за общей активностью сети, чтобы по крайней мере знать о возникновении непредвиденных ситуаций.
Используя часы с грубой шкалой, будьте внимательны
Компьютерные часы работают, добавляя единицу к некоему счетчику через равные интервалы времени. Например, миллисекундный таймер увеличивает на единицу значение счетчика раз в 1 мс. Применение такого таймера для измерения длительности события, занимающего менее 1 мс, возможно, но требует осторожности. Конечно, некоторые компьютеры используют более точные часы, но каким бы ни был шаг таймера, всегда найдется событие, которое происходит за меньшее время. Также стоит помнить, что точность часов не всегда совпадает с точностью возвращаемого ими значения.
Например, чтобы измерить время, необходимое для передачи одного сегмента, следует считывать показания системных часов (скажем, в миллисекундах) при входе и выходе из программы транспортного уровня. Если время, требуемое для передачи одного сегмента, равно 300 мкс, то измеряемая величина будет равна либо 0, либо 1 мс, что неверно. Тем не менее если повторить измерения миллион раз, сложить все значения и разделить на миллион, то полученное среднее значение будет отличаться от истинного значения менее чем на 1 мкс.
Будьте осторожны с экстраполяцией результатов
Предположим, вы что-нибудь измеряете (например, время ответа удаленного хоста), моделируя нагрузку сети от 0 (простой) до 0,4 (40 % максимальной пропускной способности). Пусть время ответа при отправке VoIP-пакета по сети 802.11 будет таким, как показано жирной линией на рис. 6.43. Может оказаться соблазнительным линейно экстраполировать полученную кривую (пунктир). Однако в действительности многие параметры в теории массового обслуживания содержат в качестве сомножителя 1/(1 - р), где р — нагрузка, поэтому истинная кривая зависимости будет больше походить на гиперболу, показанную штриховой линией, особенно при большой нагрузке. Таким образом, следует обращать внимание на влияние конкуренции, которое усиливается при большой нагрузке.
Рис. 6.43. Зависимость времени ответа от нагрузки
6.6.3. Проектирование хостов для быстрых сетей
Измерения и настройки часто позволяют значительно улучшить производительность сети, однако они никогда не заменят хорошо разработанного проекта. Плохо спроектированная сеть может быть усовершенствована только до определенного уровня. Для дальнейшего увеличения производительности ее потребуется переделать с нуля.
В данном разделе мы рассмотрим несколько эмпирических правил, относящихся к программной реализации сетевых протоколов на хостах. Опыт показывает, что это, как правило, и является ограничивающим фактором производительности в случаях, когда сеть сама по себе работает быстро. Так происходит по двум причинам. Во-первых, сетевые карты (NIC) и маршрутизаторы разрабатываются так, чтобы они могли работать со скоростью сети. То есть они могут обрабатывать пакеты с той скоростью, с которой пакеты поступают. Во-вторых, нас интересует производительность, которая доступна приложениям. А она вычисляется не исходя из мощности канала, а исходя из пропускной способности и задержки, которые являются результатом работы сетевого и транспортного уровней.
Уменьшение накладных расходов из-за программного обеспечения улучшает производительность за счет повышения пропускной способности и снижения задержки. Оно также позволяет снизить затраты энергии, необходимые для передачи данных по сети, что актуально для мобильных компьютеров. Большинство этих идей известны разработчикам сетей уже много лет. Впервые они были записаны в явном виде Моголом (Mogul, 1993). Наше повествование во многом пересекается с его книгой. Другим источником по этой же теме является (Metcalfe, 1993).
Скорость центрального процессора важнее скорости сети
Длительные эксперименты показали, что почти во всех сетях накладные расходы операционной системы и протокола составляют основное время задержки сетевой операции. Например, теоретически минимальное время удаленного вызова процедур (RPC, Remote Procedure Call) в сети Ethernet мощностью 1 Гбит/с составляет 1 мкс, что соответствует минимальному запросу (512 байт), на который приходит минимальный (512-байтовый) ответ. На практике значительным достижением считается хотя бы какое-нибудь снижение накладных расходов, возникающих за счет программного обеспечения при вызове удаленной процедуры. Что происходит редко.
Аналогично, при работе с гигабитной линией основная задача заключается в достаточно быстрой передаче битов из буфера пользователя в линию, а также в том, чтобы получатель смог обработать их с той скоростью, с которой они приходят. Удвоение производительности процессора и быстродействия памяти нередко может привести к почти удвоению пропускной способности. Удвоение же пропускной способности линии часто не дает никакого эффекта, если узким местом являются хосты.
Уменьшайте число пакетов, чтобы уменьшить накладные расходы
Каждый сегмент содержит определенное количество накладных расходов (например, заголовок) и данные (например, полезную нагрузку). Оба эти компонента требуют пропускной способности. Также каждому из них требуется обработка (например, обработка заголовка и вычисление контрольной суммы). При отправке 1 млн байт побайтовые затраты времени процессора на обработку не зависят от размера сегмента. Однако при использовании 128-байтовых сегментов затраты на обработку заголовков будут в 32 раза выше, чем для сегментов размером 4 Кбайт. И эти затраты увеличиваются очень быстро.
Накладные расходы более низких уровней усиливают этот эффект. Каждый раз прибытие каждого пакета вызывает новое прерывание, если хост работает в активном режиме. В современных конвейерных процессорах каждое прерывание нарушает работу процессорного конвейера, снижает эффективность работы кэша, требует изменения контекста управления памятью, аннулирует таблицу предсказания переходов и требует сохранения в стеке значительного числа регистров процессора. Таким образом, уменьшение на n числа посылаемых сегментов дает снижение числа прерываний и накладных расходов в целом в n раз.
