Tux: втрое быстрее лидера

EWEEK LABS // СПЕЦИАЛЬНЫЙ РЕПОРТАЖ

Производительность Web-серверов выходит в новое измерение

Генри Балтазар, Тимоти Дик

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

Так, в частности, произошло во время недавней экспертизы Web-серверов в Тестовом центре eWeek Labs. Сервер Tux 2.0 фирмы Red Hat, функционирующий на Linux с ядром версии 2.4, продемонстрировал немыслимую ранее скорость и показал, в направлении какой архитектуры должны развиваться другие подобные пакеты.

Тестирование Tux производилось в тесном сотрудничестве с группой повышения производительности корпорации Dell Computers (именно она первой опубликовала сообщение о высочайшей скорости работы Tux при проведении эталонного теста SPECWeb 99). Совместная экспертиза подтвердила, что при обслуживании смешанного динамического и статического Web-содержимого новинка Red Hat способна работать почти в три раза быстрее основного Web-сервера сегодняшнего дня Apache (12 792 транзакции в секунду против 4602).

Правда, статическое Web-содержимое имело объем всего 60,7 Мб и легко умещалось в ОЗУ, поэтому данный эталонный тест смог продемонстрировать преимущественно возможности программы по сетевому взаимодействию и управлению потоками, но не потенциал дисковой подсистемы (хотя мы и включили запись log-файлов Web-сервера).

Переоценка серверных скоростей

Впечатляющая скорость, которую Tux демонстрирует даже на не слишком производительном оборудовании, позволяет в полной мере оценить возможности его необычной архитектуры. Во-первых, исполняемый код этого Web-сервера встроен непосредственно в ядро, а считывание Web-страниц производится напрямую из кэша файловой системы, также размещенного в ядре Linux. Во-вторых, для обслуживания соединений используется небольшой набор рабочих потоков (в Apache для каждого подключения создается собственный процесс). В-третьих, управление потоками осуществляется на основе высокопроизводительного алгоритма, сводящего к минимуму влияние дисковой подсистемы на общую скорость работы.

Tux очень просто развертывается в корпоративной среде, причем устанавливать этот продукт можно поэтапно. Здесь на помощь приходит его способность совершенно прозрачно пересылать те Web-запросы, которые он не может обработать самостоятельно, на другие Web-серверы (например, Apache). Но есть у Tux и слабые места, главное из которых - отсутствие поддержки протокола SSL. Такая функция должна появиться в следующей версии продукта.

По скорости работы Tux 2.0 значительно превосходит даже Internet Information Server 5.0 из Windows 2000 (5137 запросов в секунду), что наглядно демонстрирует преимущества новой архитектуры над традиционными Web-серверами. И неслучайно в следующей версии IIS (она должна появиться одновременно с ОС Whistler) корпорация Microsoft собирается использовать ряд идей, уже реализованных в Tux, включая встраивание кода сервера непосредственно в ядро.

А если вспомнить, что впервые Web-кэш (но не Web-сервер) был встроен в ядро еще в 1999 г. (это сделала корпорация IBM в своей ОС AIX), то станет ясно: тенденция распространяется все шире.

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

Ядро 2.4 оставляет ядро 2.2 позади

В ходе тестирования мы стремились также количественно оценить прирост масштабируемости и производительности ядра Linux 2.4. Полученные результаты совершенно ясно свидетельствуют: и с Web-сервером Tux, и с Apache платформа Linux 2.4 работает гораздо быстрее, чем Linux 2.2 (дополнительный результат эталонного тестирования приводится по адресу: www.eweek.com/links).

Как уже говорилось, внутренняя архитектура Tux разрабатывалась с прицелом на наивысшую производительность, однако достигнутые результаты объясняются не только этим. По словам ведущего разработчика Red Hat (Берлин, Германия) Инго Молнара, архитектура - лишь один из пяти ключевых факторов, определяющих большую производительность Web-сервера. Остальные четыре новшества относятся к ядру Linux 2.4, и они должны существенно ускорить работу в этой среде вообще любых серверных приложений. Это технология нулевого сетевого копирования (zero copying TCP/IP), структурное связывание (affinity) прерываний и процессов ЦП, выделение ресурсов памяти ядра отдельным процессорам (так называемые slab caches) и плановое “пробуждение” процессов (чтобы воспользоваться некоторыми из этих функций, включая сетевое взаимодействие с нулевым копированием, необходимо сначала модернизировать серверные приложения).

Очень важным аспектом повышения производительности Молнар считает и проделанную работу по настройке ядра Linux 2.4 для обеспечения симметричной многопроцессорной обработки (SMP). “Чтобы достичь высокой масштабируемости SMP, нужно тщательно продумать огромное множество малых шагов и провести детальное профилирование системы, - отмечает он. - А главной целью создания ядра 2.4 считалось именно обеспечение масштабируемости на уровне предприятия”.

При сетевом взаимодействии с нулевым копированием драйвер сетевой платы получает прямой доступ к части дискового кэша (находящегося в ядре) или буфера памяти (в пространстве данных пользователя), содержащих данные, подлежащие пересылке. В традиционных технологиях ядро сначала должно скопировать данные из дискового кэша в отдельный сетевой буфер и лишь после этого может переслать их на адаптер.

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

Серьезным нововведением является и плановое “пробуждение” процессов - оно значительно повышает производительность приложений на многопроцессорных серверах.

В среде Linux 2.2 после прихода данных извне (например, из сети) запускались (“пробуждались”) все процессы, ожидающие поступления таких данных. Однако такой запрос передавался для обработки только одному процессу, а остальные за недостатком данных вновь переходили в состояние ожидания. Что же касается Linux 2.4, то здесь при появлении внешних данных запускается только один процесс, благодаря чему удается сэкономить ресурсы ЦП. 4

Со старшим аналитиком Генри Балтазаром можно связаться по адресу: henry_baltazar@ziffdavis.com, а с директором eWeek на Западном побережье США Тимоти Диком - по адресу: timothy_dyck@ziffdavis.com.

Каверзы и тонкости эталонного тестирования

Эталонная проверка Web-серверов проводится в eWeek Labs так же, как и в большинстве других тестовых центров. Это - непрерывный поток проб и ошибок, в ходе которого мы используем все доступные средства, чтобы максимально загрузить свои серверы на базе Tux, Apache и IIS.

Подобно всем настоящим техноманам, аналитики eWeek Labs не могли не восхищаться экстраординарными показателями, продемонстрированными Tux 1.0 год с лишним назад в ходе эталонного теста SPECWeb 99. На этот раз мы решили проверить продукт с помощью собственной тестовой платформы WebBench и посмотреть, сможет ли Tux повторить свои феноменальные результаты годичной давности. Тестирование производилось на оборудовании лаборатории eTesting Labs, расположенной в г. Фостер-Сити (шт. Калифорния). Она принадлежит фирме Ziff-Davis Media, издающей и журнал eWeek.

Производительность Tux остается непревзойденной  

В ходе экспертизы использовалась смешанная нагрузка, состоящая на 30% из динамического содержимого и на 70% - из статического.

К сожалению, стандартный динамический модуль WebBench для Apache базируется на сильно устаревшем коде CGI. Это не позволило сопоставить его показатели с модулем ISAPI, который был создан для Web-сервера IIS из состава Windows 2000.

Чтобы обеспечить равную нагрузку на платформы, мы привлекли к тестированию инженеров корпорации Dell Computers, Red Hat (эта фирма разработала Tux), Apache Software Foundation и Microsoft. Им было предложено написать модули динамического содержимого для каждого проверяемого варианта (“чистый” Tux, Tux с динамическим Apache в качестве серверного компонента и IIS). Исходные тексты модулей можно найти на узле www.eweek.com/links.

Хотя все использованные модули создавали те же самые HTML-страницы, что и стандартные модули WebBench, они разрабатывались отдельно и никакой связи с кодами WebBench не имели. Таким образом, результаты нашего тестирования нельзя ни рассматривать как официальные, ни сравнивать с другими тестами WebBench.

Самой большой неожиданностью для нас стала невозможность полностью загрузить Web-сервер на базе Tux в стандартной аппаратной конфигурации. В конце концов нам пришлось демонтировать два из четырех процессоров сервера Dell PowerEdge 6400 (он был оснащен двумя сетевыми адаптерами Gigabit Ethernet и ОЗУ емкостью 2 Гб). Только после этого 80 рабочих станций смогли создать достойную нагрузку серверу Tux (см. график).

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

Со старшим аналитиком Генри Балтазаром можно связаться через Интернет по адресу: henry_baltazar@ziffdavis.com.