Network World, США
В клиентских Web-ускорителях применяются разные способы быстрой доставки контента, в том числе коммутация прикладного уровня, сжатие трафика HTTP и мультиплексирование TCP-соединений. Проблема заключается в том, что эти устройства либо значительно ускоряют доставку трафика ограниченному числу пользователей, либо «медленно» обслуживают многих потребителей, но не способны делать то и другое одновременно.
Впервые в индустрии мы провели комплексные испытания клиентских Web-ускорителей. Почти год мы тестировали продукты шести ведущих производителей — Array, Citrix, Crescendo Networks, F5 Networks, Foundry Networks и Juniper Networks. И вот — некоторые наши выводы.
- Преимущества использования ускорителей вполне реальны. Они увеличивают скорость доставки контента и одновременно снижают нагрузку на серверы центров обработки данных.
- Сжатие HTTP-трафика не всегда уменьшает время отклика, а иногда даже увеличивает его - в том числе при работе с хорошо сжимаемыми текстовыми объектами и при очень низких скоростях доступа клиентских терминалов.
- Мультиплексирование TCP-соединений позволяет значительно (до 350 раз) уменьшить серверную нагрузку, связанную с обработкой сетевого трафика.
- Некоторые устройства не могут обрабатывать трафик TCP-соединений, если пользователь очень быстро запрашивает Web-страницы (например, при работе с сайтом электронной коммерции).
- Продукты разных фирм сильно различаются по максимальному числу поддерживаемых соединений и максимальной скорости передачи трафика.
Протестированные нами изделия заметно различаются по физическим размерам, функциональности и требованиям к топологии сети, но их объединяет общая черта — ни одно устройство не сумело успешно пройти все испытания. Это заставило нас воздержаться от выставления итоговых оценок. Тем не менее два продукта заслуживают отдельного упоминания. Web-ускоритель CN5080-E компании Crescendo продемонстрировал во многих тестах выдающуюся производительность благодаря применению в нем патентованных аппаратных средств коммутации контента. А NetScaler Application Delivery System фирмы Citrix удачно сочетает высокую масштабируемость с множеством функций.
Переходим к тестированию
Наша основная цель состояла в оценке производительности ускорителей. В сервисных тестах измерялись скорость выполнения транзакций и время отклика для заданного числа пользователей. Испытания проводились как с включенными, так и с выключенными средствами сжатия трафика HTTP и списками контроля над доступом, а также с имитацией распределенной сетевой DoS-атаки. В тестах на масштабируемость мы попытались выявить предел системной производительности с точки зрения максимального числа одновременно поддерживаемых соединений, эффективности TCP-мультиплексирования и наивысших скоростей передачи.
Мы не утверждаем, что какой-либо набор тестов позволяет получить точное представление о функционировании этих устройств. При оценке нагрузки на прикладном уровне в игру вступают слишком много факторов, чтобы результаты испытаний можно было напрямую распространить на реальные сети. Однако они дают возможность сравнить продукты разных компаний, ведь каждое устройство имело дело с одним и тем же трафиком.
Тестовая среда имитировала 2,35 млн уникальных клиентов и 16 Web-серверов. В некоторых испытаниях мы отправляли на устройства трафик со скоростью передачи, соответствующей быстродействию гигабитных локальных сетей Ethernet. Порой она достигала 4 Гбит/с. При оценке масштабируемости нас интересовали число обслуживаемых пользователей и скорость обработки транзакций, а не пропускная способность.
Результаты тестирования показывают, что производители сконцентрировались на оптимизации разных аспектов функционирования своих устройств. Одни продукты снимают с серверов значительную часть нагрузки, связанной с обработкой TCP-заголовков, а другие используют сжатие HTTP-трафика для уменьшения времени отклика. Ускорители существенно различаются по способности одновременно поддерживать множество соединений и по скорости передачи трафика приложений, которая характеризует время доставки запрошенного HTTP-объекта на клиентский компьютер.
Лучшая рекомендация пользователям такова: определите самую важную для вас характеристику Web-ускорителей и купите продукт, который сулит наибольший выигрыш именно в этой области.
В поисках пределов
Тесты на масштабируемость должны были помочь пользователям сопоставить возможности Web-ускорителей с потребностями их сетей. Сначала мы попытались определить максимальное число клиентских соединений, поддерживаемых каждым Web-ускорителем. Конфигурация эмулятора Avalanche производства Spirent была настроена на имитацию 4 млн клиентов, запустивших Internet Explorer. Каждый из них инициировал TCP-соединение и запросил загрузку Web-объекта размером 1 Кбайт с одного или нескольких виртуальных IP-адресов Web-ускорителя. Как известно, за одним IP-адресом сайта типа www.amazon.com скрываются десятки, если не сотни серверов. Все Web-ускорители использовали один виртуальный proxy-адрес IP для доступа к множеству серверов тестовой среды.
Получив требуемый объект, клиент выжидал 60 с и запрашивал загрузку нового объекта по тому же соединению. Столь продолжительное время «размышления» позволило нам точно подсчитать число соединений. Для каждого устройства мы добавляли новые соединения до тех пор, пока оно не начинало ошибаться при обработке некоторых транзакций либо пока не достигалось предельное число соединений (в нашей тестовой среде оно составляло 4 млн). Хотя требовалось подсчитать число установленных соединений четвертого уровня, на котором используется протокол TCP, в этом и других тестах мы задействовали средства коммутации седьмого уровня.
NetScaler Application Delivery System производства Citrix достиг предельного числа TCP-соединений (4 млн), за ним последовали устройства BIG-IP фирмы F5 (около 3,5 млн) и ServerIron 450 компании Foundry (2,7 млн). Для ускорителя DX 3600 корпорации Juniper максимальный показатель составил 2 млн соединений, да и то при условии, что в сети работали сразу четыре устройства. Один ускоритель обслуживал не более 500 тыс. соединений. Изделия Crescendo и Array чуть-чуть не дотянули до 1 млн одновременно поддерживаемых TCP-соединений. Представители Crescendo сообщили, что масштабируемость их продукта на аппаратном уровне ограничена именно таким числом соединений, небольшая часть которых используется для внутренних нужд.
Сотрудники Foundry подвергли критике нашу методологию тестирования, заявив, что мы проверяем скорость установления новых соединений, а не число одновременно поддерживаемых соединений. По их словам, выпускаемый Foundry ускоритель ServerIron способен установить до 7 млн одновременных соединений, если запросы на формирование соединений или загрузку очередных Web-страниц поступают не очень часто.
В идеале, скорость установления соединений и их общее число должны оцениваться независимо, но ограниченные сроки тестирования не позволили нам повторить испытания с меньшей скоростью генерации запросов. Тем не менее полученные цифры вполне корректны, поскольку условия тестирования были одинаковыми для всех изделий.
TCP-мультиплексирование
Все шесть устройств поддерживают TCP-мультиплексирование, но 300-кратное различие в результатах свидетельствует, что эта поддержка реализована по-разному. TCP-мультиплексирование обеспечивает заметный выигрыш в производительности, поскольку освобождает серверы от обработки TCP-пакетов, требующей немалых вычислительных ресурсов. Мы отнесли TCP-мультиплексирование (наряду с коммутацией седьмого уровня) к обязательным функциям, которые должен поддерживать каждый продукт.
Перед началом теста эмулятор Avalanche был сконфигурирован на формирование и поддержку 100 тыс. клиентских TCP-соединений. Клиенты запрашивали загрузку титульных страниц разных сайтов. Подождав 60 с, мы сопоставляли число клиентских соединений, которое всегда равнялось 100 тыс., с количеством соединений на стороне сервера. Отношение этих двух чисел характеризовало эффективность мультиплексирования. Отметим, что на него могла влиять продолжительность паузы перед выдачей клиентами очередного запроса. Для одних устройств это влияние оказалось весьма существенным, а для других практически отсутствовало.
Мы начали с трехсекундной паузы, которую даже не назовешь задержкой. Это значение, скорее, отражает тот факт, что посетители сайтов электронной коммерции порой очень быстро переходят от страницы к странице. Затем тест был повторен с 60-секундной задержкой. Для ряда устройств увеличение паузы привело к более высоким отношениям чисел мультиплексируемых соединений (рис. 1).
|
| Рис. 1. Эффективность TCP-мультиплексирования |
Наилучший результат показал продукт фирмы Citrix, сумевший при 60-секундной паузе «втиснуть» 346 клиентских соединений в одно серверное. Подобная эффективность мультиплексирования означает весьма значительное снижение серверной нагрузки. Но при трехсекундной паузе картина оказалась иной. На каждое серверное соединение устройство NetScaler Application Delivery System сумело сформировать только три клиентских, т.е. эффективность мультиплексирования снизилась в 100 раз! Представители Citrix сообщили нам, что обеспечиваемая их продуктом эффективность мультиплексирования обычно гораздо выше. Они объяснили низкий показатель отсутствием кэширования и высокой скоростью формирования транзакций в ходе тестирования.
Web-ускоритель производства Crescendo при 60-секундной паузе мультиплексировал клиентские TCP-соединения в отношении 100:1, а при трехсекундных паузах отношение составило 60:1. Ни мы, ни производитель не смогли объяснить этот результат: в более ранних тестах с другой версией ПО устройство CN5080E постоянно формировало 1024 соединения с сервером — вне зависимости от промежутка времени перед генерацией очередного запроса и даже при отсутствии пауз.
Результаты работы продукта ServerIron компании Foundry также оказались загадочными. В предварительных испытаниях отношение чисел соединений составляло 50:1 вне зависимости от продолжительности паузы. После обновления программного кода отношение опустилось ниже 2:1.
В продуктах других фирм средства TCP-мультиплексирование не дают особого выигрыша. Скажем, для одиночного устройства компании Juniper отношение чисел TCP-соединений было меньшим двух независимо от продолжительности паузы. При наличии в тестовой среде сразу четырех устройств указанное отношение выросло до 5:1, но лишь при 60-секундной паузе.
|
| Рис. 2. TCP-мультиплексирование и скорость обработки транзакций |
Чтобы выяснить причины подобных различий, мы проанализировали скорость обработки транзакций каждого из устройств (рис. 2). Эмулированные клиенты всегда запрашивали загрузку объектов с одной и той же частотой, поэтому разница скоростей обработки транзакций могла быть связана лишь со временем отклика самих Web-ускорителей. Как и следовало ожидать, чем большей была скорость обработки транзакций, тем большим оказывалось и отношение чисел мультиплексируемых соединений. Исключение из этого правила продемонстрировал лишь DX 3600 производства Juniper.
Отношение чисел соединений 100:1 вовсе не означает, что в реальной сети 100 серверов удастся заменить на один. Здесь важны несколько факторов, в том числе степень утилизации ресурсов серверного ЦП и памяти, сетевая нагрузка и особенности поведения приложений. Но даже приняв их во внимание, следует признать, что мультиплексирование TCP-соединений дает огромные преимущества при построении серверных кластеров.
|
Производительность прикладного уровня
таблицаПоскольку некоторые устройства имели по 16 портов Gigabit Ethernet, у нас возник закономерный вопрос: насколько быстро они передают данные? Мы измерили «прикладную производительность» (goodput) каждого устройства в соответствии с ее определением в спецификации RFC 2647: это объем полученных данных за вычетом потерянных или повторно отосланных. Определенная таким образом величина и в самом деле является производительностью на прикладном уровне модели OSI. Она показывает, насколько быстро Web-ускоритель отправляет запрошенный HTTP-объект на клиентское устройство.
Мы сформировали 100 эмулированных клиентов, каждый из которых выдавал на сервер запрос о загрузке 1-мегабайтных объектов. Как и в других испытаниях, мы использовали различные URL-указатели для каждого объекта, заставляя устройства принимать решения о коммутации на седьмом уровне.
Сначала мы оценили значение «чистой» производительности при отсутствии ускорителей, которое характеризовало возможности самого канала передачи. Оно составило 3,8 Гбит/с, что близко к теоретическому максимуму, если принять во внимание объем служебной информации, которую привносят протоколы Ethernet, IP, TCP и HTTP. Ни одно из устройств даже близко не подошло к данному показателю. Продукты Array, Citrix и Juniper имели меньше четырех клиентских и серверных интерфейсов, поэтому в принципе не могли достичь величины «чистой» производительности. Ускоритель Array и устройство Juniper имели по одному клиентскому интерфейсу, а продукт Citrix — два. Тем не менее результаты, продемонстрированные устройствами Array и Citrix, оказались гораздо лучшими, чем у изделий с четырьмя интерфейсами: оба продукта вплотную приблизились к максимальным показателям, которые соответствовали их числу интерфейсов.
Реальные значения производительности прикладного уровня оказались заметно меньшими теоретического максимума. Лучший результат, чуть больше 3 Гбит/с, продемонстрировал CN5080E фирмы Crescendo, да и то благодаря аппаратному ускорению пересылки пакетов. Второе место с показателем 2,5 Гбит/с занял BIG-IP компании F5. По утверждению ее представителей, это значение зависит от числа обслуживаемых клиентов: в тестах с 1 и 10 тыс. клиентами, которые разработчик организовал собственными силами, производительность прикладного уровня достигла 3,2 Гбит/с. А значит, число пользователей действительно влияет на производительность.
ServerIron 450 компании Foundry «выдал» производительность 1,9 Гбит/с, примерно в два раза меньшую максимальной. Отметим, что с предыдущей версией ПО для этого устройства мы получали не менее 2,7 Гбит/с, а сам изготовитель сумел преодолеть 3-гигабитную планку.
Конфигурация из четырех устройств Juniper оказалась самой медленной среди ускорителей с четырьмя интерфейсами. Впрочем, производителя это не смутило, поскольку он придает гораздо большее значение функциям кэширования и сжатия трафика.
Всем не угодишь
Во время испытаний мы всякий раз стремимся не сравнивать яблоки с апельсинами. Однако в силу требований производителей и различий в дизайне отдельных устройств нам не всегда удается четко придерживаться этого принципа.
Компания Juniper предоставила нам конфигурацию из четырех устройств DX 3600, объединенных при помощи системы высокой надежности ActiveN. Представители Redline Networks (которую Juniper купила уже после начала испытаний) категорически настаивали на использовании именно такой конфигурации. Мы вынуждены были согласиться, хотя и оговорили возможность тестирования одиночного ускорителя DX 3600.
Возможно, сетевым администраторам придутся по душе повышенные производительность и надежность, которые достигаются благодаря объединению четырех устройств, но не стоит сбрасывать со счетов и обусловленный этим рост цены. Естественно, другие компании также могли бы повысить производительность своих разработок, передав нам несколько объединенных в систему Web-ускорителей.
Особенности архитектуры разных моделей наложили отпечаток на топологию тестовой сети. Изделия компаний Array, Citrix и Juniper требуют применения коммутатора второго уровня для передачи трафика по клиентской и серверной локальным виртуальным сетям. Продукты Crescendo, F5 и Foundry прекрасно обходятся без дополнительного коммутатора, хотя сотрудники Foundry, поразмыслив, все-таки попросили его установить. Наконец, в Web-ускорителе фирмы Crescendo каждый порт находится в собственной IP-подсети, поэтому трафик не коммутируется между интерфейсами, а маршрутизируется с одного интерфейса на другой.
Мы не думаем, что минимальные различия во времени задержек, обусловленные наличием дополнительных коммутаторов и составляющие десятки микросекунд, существенно повлияли на результаты тестирования. Тем не менее проектировщики сетей должны учитывать, что разные Web-ускорители требуют немного различающихся сетевых топологий.
Процедура тестирования
Многообразие функций клиентских Web-ускорителей заставило нас ограничить список тестируемых продуктов теми, которые поддерживают мультиплексирование TCP-соединений и принимают решения о дальнейшей транспортировке трафика на основе лишь содержимого пакетов седьмого уровня, например URL.
Тестовая среда имитировала 2,35 млн Web-клиентов, на которых был запущен Internet Explorer, и 16 серверов, работавших под управлением Internet Information Services. Для эмуляции клиентов и серверов использовались две пары генераторов/анализаторов, Avalanche и Reflector 2500 компании Spirent Communications. Для соединения устройств в сети были установлены коммутатор Summit 7i производства Extreme Networks и виртуальная коммутационная панель фирмы Apcon.
Для оценки числа одновременно поддерживаемых соединений клиенты, эмулированные устройствами Avalanche, запрашивали на каждом из ускорителей загрузку объектов «весом» 1 Кбайт с виртуального IP-адреса. Ускоритель распределял запросы по серверам, которые эмулировались устройствами Reflector. При отсутствии ускорителя пара Avalanche/Reflector могла формировать до 4 млн соединений.
Чтобы обеспечить коммутацию седьмого уровня, мы использовали списки URL-адресов, в которых каждый четный запрос заканчивался символом подчеркивания. Ускорители были настроены на отправку запросов с адресами без подчеркивания на первые восемь серверов, а запросов с подчеркиванием — на оставшиеся восемь серверов. Другими словами, перед трансляцией запроса Web-ускоритель должен был проанализировать URL-адрес.
В тесте на мультиплексирование TCP-соединений загружались титульные страницы серверов Amazon.com, BBC, UCLA, Белого дома и Yahoo, которые содержат текстовые и графические элементы. С намерением гарантировать работу средств коммутации седьмого уровня мы попросили производителей так настроить конфигурации их устройств, чтобы запросы на загрузку графического контента (файлы .gif и .jpg) передавались на второй пул из восьми серверов, а все остальные запросы — на первый пул.
При измерении времени отклика и скорости обработки транзакций мы использовали те же пять Web-серверов, что и в тесте на мультиплексирование, но с двумя существенными изменениями. Во-первых, мы сформировали три класса пользователей с тремя типами доступа — коммутируемым (53 Кбит/с), DSL/CATV (1,5 Мбит/с) и по локальной сети (1 Гбит/с). Во-вторых, структура генерируемого трафика позволяла поддерживать постоянное соотношение пользователей трех указанных классов — 40:40:20. Общее количество пользователей выбиралось равным 1, 10 и 100 тыс.
Для измерения сжатия HTTP-трафика 1 тыс. клиентов одновременно запрашивали загрузку одного текстового объекта размером 500 Кбайт (который теоретически должен хорошо сжиматься). Правда, производители просили нас включать функцию сжатия только для коммутируемого и DSL/CATV-соединений. В тестах с объектами размером 500 Кбайт и загрузкой домашних страниц измерялись скорость обработки транзакций и среднее время отклика при обращении к конкретной странице или URL-адресу (см. рисунок).