Большие гонки веб-серверов::Журнал СА 3.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 5101
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6343
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7599
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7922
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6979
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Большие гонки веб-серверов

Архив номеров / 2007 / Выпуск №3 (52) / Большие гонки веб-серверов

Рубрика: Веб /  Веб

Сергей Супрунов

Большие гонки веб-серверов

Современная жизнь немыслима без Интернета, а Интернету необходимы веб-серверы. Смутное подозрение, что Apache – далеко не единственный HTTP-сервер в мире, подтолкнуло меня на проведение небольшого исследования в этой области.

Как отбирались претенденты

Подручной тестовой платформой была операционная система FreeBSD, поэтому в кандидаты на «обозрение» попали только приложения, присутствующие в коллекции Портов. По «make search» в различных комбинациях в каталоге /usr/ports/www были выявлены 30 пакетов, претендующих на звание веб-сервера.

1-й этап

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

В результате отсеялись 7 серверов (AOLServer, caudium, dhttpd, fhttpd, lws, roxen и tclhttpd), как не подающие признаков жизни либо давно не обновлявшиеся в коллекции Портов.

Для веб-сервера micro_httpd (его версия в Портах тоже сильно устарела) в порядке исключения, учитывая его мизерный размер, было принято решение провести тестирование свежей версии, собранной вручную из исходников (при условии, что сборка пройдёт успешно).

Таким образом, до следующего этапа добралось 23 приложения.

Замечание: поскольку Apache 1.3 и Apache 2.2 значительно отличаются друг от друга, то они в обзоре рассматривались как разные веб-серверы; ветку 2.0, как промежуточный продукт, было решено не рассматривать.

2-й этап

После отсева «по документам» претендентов ждало следующее испытание – установка в систему. Для удобства тестирования при инсталляции были нарушены традиции размещения вновь устанавливаемого ПО в каталог /usr/local, и для всех пакетов в качестве префикса указывался /usr/local/<имя_веб-сервера>.

Все пакеты устанавливались из коллекции Портов с параметрами по умолчанию, то есть установка выполнялась таким образом:

# cd /usr/ports/www/<имя_веб-сервера>

# make depends

# make install PREFIX=/usr/local/<имя_веб-сервера>

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

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

Тестирование выполнялось на машине Celeron 433 МГц/192 Мб/40 Гб IDE под управлением FreeBSD 6.2 в среде jail. Поэтому результаты испытаний следует трактовать применительно к использованию на серверах класса SOHO – на высокопроизводительном многопроцессорном оборудовании они могут отличаться от полученных.

Учитывая большое число претендентов, при тестировании учитывался заявленный функционал, обращалось внимание на такие субъективные моменты, как удобство настройки и качество документации, и «на сладкое» запускались четыре теста производительности.

Во-первых, проверялась работа с маленьким (3 Кб) и большим (1,1 Мб) статическими документами и с тестовым CGI-скриптом из поставки Boa (для серверов, поддерживающих данную функциональность). Выполнялись эти тесты утилитой ab, устанавливаемой с сервером Apache 1.3, запускаемой на этой же машине (что ещё раз подчёркивает ориентированность обзора на класс SOHO, где веб-сервер редко является единственным приложением и зачастую вынужден делить ресурсы системы с другими службами). Каждый из тестов запускался с уровнем конкуренции, т.е. числом параллельных запросов, равным 1 (1000/1), 10 (1000/10) и 100 (1000/100).

Для четвёртого теста использовалась утилита WART 4.0 (спасибо Сергею Яремчуку за прекрасный обзор в №12 за 2006 год), работающая на отдельном компьютере P4-2,4 ГГц/384 Mб/40 Гб IDE под управлением Windows XP, соединённая с сервером по локальной сети на скорости 10 Мбит/с («сторонняя» нагрузка на сеть во время выполнения тестов была пренебрежимо мала). Тест включал в себя запрос трёх статических документов (два по 3 Кб и один – 12 Кб) на протяжении 2 минут при 20 одновременно работающих «пользователях». Показанные графики получены именно ею.

Хотя некоторые серверы (например, Apache 1.3, Apache 2.2, nginx) допускают тонкую подстройку производительности, способную повлиять на результаты тестирования, в обзоре использовались настройки по умолчанию.

Для Apache 2.2 и nginx «вне конкурса» была проверена работа с максимальным числом процессов выше устанавливаемого по умолчанию.

Переходим к обзору

Итак, настало время поближе познакомиться с претендентами на звание самого шустрого, умелого и весёлого!

Apache 1.3

  • Версия: 1.3.37.
  • Путь в дереве портов: www/apache13.
  • Размер архива: 2603 Кб (от 27.07.2006).
  • Сайт разработчикаhttp://httpd.apache.org.

Про Apache, думаю, слышал каждый – это самый распространённый веб-сервер, широко используемый на различных задачах от «тестовой» инсталляции на домашней машине для отладки разрабатываемых PHP-сценариев до самых посещаемых порталов, ежесекундно отправляющих в Интернет гигабайты информации.

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

В WART-тесте после небольшой «раскачки» была продемонстрирована скорость обработки запросов на уровне 44 страницы в секунду при загрузке процессора примерно на 60% (см. рис. 1 и таблицу 1).

Таблица 1. Apache 1.3

Тест

1000/1

1000/10

1000/100

«Малый статик»

4.508

4.631

4.440

«Большой статик»

110.960

112.864

116.917

«Чистый CGI»

192.214

185.192

201.035

Рисунок 1. Apache 1.3

Рисунок 1. Apache 1.3

Вывод: тесты показали очень высокую устойчивость к нагрузкам – число одновременных запросов практически не влияло на общее время выполнения тестов. Ошибок не наблюдалось. Производительность – одна из самых высоких.

Apache 2.2

  • Версия: 2.2.4.
  • Путь в дереве портов: www/apache22.
  • Размер архива: 4814 Кб (от 06.01.2007).
  • Сайт разработчикаhttp://httpd.apache.org.

Вторая версия Apache. Основное отличие от версии 1.3 – переход к «многопоточной» архитектуре, когда один процесс может одновременно обслуживать несколько запросов.

На редкость долгая сборка – 34 минуты. Разбираться не стал (собралось, и ладно), но неприятный осадок остался. В конфигурации нужно не забыть открыть (в секции <Directory />) доступ как минимум с хоста, откуда выполняется тестирование – по умолчанию там стоит «Deny from all».

Единственный веб-сервер, загнавший при выполнении тестов значение «Load average» аж до 110. Для FreeBSD это ощутимо. В WART-тесте, тоже после «раскачки», достиг 37 запросов в секунду, нагружая процессор на 40-45% (см. рис. 2 и таблицу 2).

Таблица 2. Apache 2.2

Тест

1000/1

1000/10

1000/100

«Малый статик»

5.853

5.099

5.938

«Большой статик»

70.111

61.319

63.730

«Чистый CGI»

191.266

190.438

216.518

Рисунок 2. Apache 2.2

Рисунок 2. Apache 2.2

Увеличив в конфигурации максимальное число процессов, можно поднять это значение до 42-43 запросов при загрузке процессора порядка 60%. На ab-тестах, учитывая полную загрузку процессора, такая подстройка не оказывала заметного влияния.

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

Boa

  • Версия: 0.94.14.r20,1.
  • Путь в дереве портов: www/boa.
  • Размер архива: 163 Кб (от 10.06.2004).
  • Сайт разработчикаhttp://www.boa.org.

Основной конфигурационный файл boa.conf (пример можно найти в share/examples/boa/boa.conf) прокомментирован весьма щедро, многие директивы очень похожи на аналогичные в конфигурации Apache.

Для начала работы нужно, как обычно, проверить настройки директив DocumentRoot – остальное можно принять по умолчанию.

Две проблемы при первой попытке запуска заключались в отсутствии файла mime.types в каталоге etc и отсутствии же прописанного в конфигурации log-файла /var/log/boa/error_log. После создания пустых файлов с соответствующими именами boa успокоился и стал запускаться. Хотя для полноценного функционирования mime-типов нужный файл придётся где-то позаимствовать (например, в поставке того же Apache).

WART показал среднюю производительность 35 страниц в секунду, с нагрузкой на процессор в районе 28-45% (см. рис. 3 и таблицу 3).

Таблица 3. Boa

Тест

1000/1

1000/10

1000/100

«Малый статик»

3.477

3.659

4.810

«Большой статик»

118.954

150.626

171.727

«Чистый CGI»

200.179

181.118

189.799

Рисунок 3. Boa

Рисунок 3. Boa

Вывод: на малых статических файлах обходит Apache 1.3 почти на 25%, ненамного отставая на других тестах. С ростом числа параллельных запросов производительность падает.

bozohttpd

  • Версия: 20060517.
  • Путь в дереве портов: www/bozohttpd.
  • Размер архива: 32 Кб (от 18.05.2006).
  • Сайт разработчикаhttp://www.eterna.com.au/bozohttpd.

Сервер позиционируется как маленький и безопасный. Скромный размер, быстрая сборка, отсутствие даже конфигурационного файла – все опции задаются в командной строке:

wwwtest# libexec/bozohttpd -b -c /var/cgi-bin -i 10.161.193.253 -I 80 -U www /var/www

В эти 32 килобайта поместилась поддержка HTTP/1.1, CGI, userdir, автоиндекса, виртуального хостинга. Однако WART-тест показал не самые впечатляющие результаты (24-27 запросов в секунду), а вот процессор при этом нагружался до 90-100% (см. рис. 4 и таблицу 4).

Таблица 4. bozohttpd

Тест

1000/1

1000/10

1000/100

«Малый статик»

15.153

16.481

21.325

«Большой статик»

109.578

116.953

129.675

«Чистый CGI»

184.605

197.998

220.072

Рисунок 4. bozohttpd

Рисунок 4. bozohttpd

Вывод: что-то страшное на небольших файлах (видимо, высока стоимость создания нового процесса). Также заметно «проседание» под нагрузкой. Для больших файлов и CGI не так плохо, но и до рекорда ещё ой как далеко.

Cherokee

  • Версия: 0.5.6 (от 14.12.2006).
  • Путь в дереве портов: www/cherokee.
  • Размер архива: 1359 Кб.
  • Сайт разработчикаhttp://cherokee-project.com.

Заявлен как быстрый, гибкий и простой в настройке веб-сервер с поддержкой FastCGI, PHP, CGI, TLS/SSL, виртуального хостинга, аутентификации.

Конфигурационный файл Cherokee выдержан в «классических тонах», т.е. если вам доводилось работать с каким-нибудь веб-сервером (можно даже попытаться угадать, с каким именно), то смысл большинства директив будет понятен без комментариев.

Пожалуй, единственное, что может сбить с толку, – это что здесь вся работа строится на принципах виртуального хостинга, и даже для запуска одного-единственного сайта вы должны настроить виртуальный хост default (etc/cherokee/sites-enabled/default). Именно здесь задаются такие параметры, как «DocumentRoot» и секция «Directory /cgi-bin».

Команда запуска: «sbin/cherokee -b». Дочерние процессы не создаются. Основной процесс, занимая в памяти около 4,5 Мб, на WART-тесте нагружал процессор всего на 25-30%, отдавая страницы примерно со скоростью 25 штук в секунду (см. рис. 5 и таблицу 5).

Таблица 5. Cherokee

Тест

1000/1

1000/10

1000/100

«Малый статик»

4.152

3.867

5.337

«Большой статик»

79.329

79.768

89.333

«Чистый CGI»

188.196

205.812

211.706

Рисунок 5. Cherokee

Рисунок 5. Cherokee

Вывод: несмотря на «проседание» при большом числе одновременных запросов, по скорости составляет серьёзную конкуренцию обоим «Апачам» при заметно меньшей нагрузке на процессор.

DFileServer

  • Версия: 1.1.3.
  • Путь в дереве портов: www/dfileserver.
  • Размер архива: 22 Кб (от 30.10.2005).
  • Сайт разработчика: не обнаружен.

Странный проект. Первое, что бросилось в глаза – отсутствие какой-либо документации, инсталлируемой вместе с сервером.

Попытка запустить «в лоб» приводила лишь к старту на 2000-м порту в текущем каталоге. Как выяснилось из скудной документации, которую можно найти в исходниках, порт указывается в параметре -port, а рабочим каталогом станет текущий. Так что запуск выполнялся таким образом:

wwwtest# cd /var/www

wwwtest# /usr/local/dfileserver/bin/dfileserver -port 80 &

В среднем 27 страниц в секунду при загрузке процессора от 30 до 80%. Пару раз на WART-тесте отмечалось падение производительности до нуля (см. рис. 6 и таблицу 6).

Таблица 6. DFileServer

Тест

1000/1

1000/10

1000/100

«Малый статик»

3.865

4.317

4.925

«Большой статик»

114.217

132.927

146.794

«Чистый CGI»

Рисунок 6. DFileServer

Рисунок 6. DFileServer

Вывод: неплохие скоростные показатели (CGI сервером не поддерживается). Учитывая небольшой размер и простоту, вполне может сгодиться для быстрого запуска чего-нибудь статического. Например, чтобы с любого компьютера в сети можно было читать html-документацию к Apache.

fnord

  • Версия: 1.10.
  • Путь в дереве портов: www/fnord.
  • Размер архива: 32 Кб (от 28.09.2005).
  • Сайт разработчикаhttp://www.fefe.de/fnord.

Ещё один «малыш» с поддержкой CGI. Сервер предполагает запуск либо с использованием tcpserver, либо с помощью inetd. Для тестирования я использовал второй способ запуска, так что в /etc/inetd.conf была добавлена строка:

http stream tcp nowait root /usr/local/fnord/bin/fnord fnord /var/www

Для проведения тестирования в переменной inetd_flags были увеличены значения максимального числа соединений и скорости поступления запросов (по умолчанию разрешено не более 60 запросов в минуту с одного IP-адреса).

Поддерживается виртуальный хостинг, реализованный с привязкой к имени запрошенного хоста. Т.е. при указании рабочего каталога /var/www и поступлении запроса http://localhost/test.html будет искаться файл /var/www/localhost:80/test.html.

WART-тест почему-то не пошёл. Загрузка процессора доходила до 100%, но WART сообщал о том, что обработано 0 запросов при 0% ошибок. В то же время с обычного браузера запросы выполнялись нормально. Видимо, какое-то несогласование формата заголовков (см. таблицу 7).

Таблица 7. fnord

Тест

1000/1

1000/10

1000/100

«Малый статик»

28.186

29.694

31.925

«Большой статик»

134.794

133.879

141.688

«Чистый CGI»

Вывод: что ещё можно было ожидать от запуска через inetd? Но зато в «демонах» постоянно не болтается...

gatling

  • Версия: 0.8.
  • Путь в дереве портов: www/gatling.
  • Размер архива: 60 Кб (от 20.05.2005).
  • Сайт разработчикаhttp://www.fefe.de/gatling.

Ещё одно детище разработчиков fnord, на этот раз «демонизированное». Заявлена поддержка автоиндекса, работы в chroot-окружении, SSL, виртуального хостинга. Кроме того, gatling является также и FTP-сервером.

Рабочие опции задаются в командной строке (-n отменяет вывод на консоль информации о работе сервера):

wwwtest# sbin/gatling -n -u www -c /var/www &

Несмотря на упоминание на сайте поддержки CGI, заставить работать её не удалось. Кстати, на man-странице нет упоминания параметра -C (в котором указывается регулярное выражение, по которому будет определяться, является ли файл cgi-сценарием), так что будем считать, что на сайте просто пошутили... Хотя не исключаю, что и я что-то не так понял.

24-26 страниц в секунду при загрузке процессора на уровне 20-25% делает gatling неплохим претендентом на часть ресурсов слабеньких машин (см. рис. 7 и таблицу 8).

Таблица 8. gatling

Тест

1000/1

1000/10

1000/100

«Малый статик»

3.147

2.736

3.349

«Большой статик»

78.647

52.225

58.582

«Чистый CGI»

Рисунок 7. gatling

Рисунок 7. gatling

Вывод: серьёзная заявка на рекорд, особенно при 10 одновременных запросах, однако 5 ошибок в тестах 1000/100 несколько портят впечатление. Также осталась непонятной ситуация с CGI.

hiawatha

  • Версия: 5.3.
  • Путь в дереве портов: www/hiawatha.
  • Размер архива: 180 Кб.
  • Сайт разработчикаhttp://hiawatha.leisink.org.

Основной особенностью этого сервера заявлена безопасность. Apache на официальном сайте назван «большой жирной коровой», хотя, забегая вперёд, скажу, что такая самонадеянность разработчиков выглядит несколько беспочвенной. Конфигурация располагается в etc/hiawatha, основной файл – httpd.conf.

Для работы с CGI-сценариями на Perl нужно раскомментировать обработчик:

CGIhandler = /usr/bin/perl:cgi

Причём cgi-скрипт не должен содержать строки «#!» – почему-то на ней возникала ошибка. Для каждого языка сценариев нужно прописывать свой обработчик.

Плавающая в пределах 30-50% загрузка процессора на WART-тесте при 30 страницах – не самый лучший результат. Даже в сравнении с «большой жирной коровой» (см. рис. 8 и таблицу 9).

Таблица 9. hiawatha

Тест

1000/1

1000/10

1000/100

«Малый статик»

6.365

5.744

8.514

«Большой статик»

113.61

118.895

174.232

«Чистый CGI»

183.590

192.081

209.090

Рисунок 8. hiawatha

Рисунок 8. hiawatha

Вывод: в общей сложности 40 ошибок (а это почти 0,5% от общего числа запросов) заставляет относиться к серверу с настороженностью. «Провал» в режиме 1000/100 на статических запросах также опускает этот сервер в область слабонагруженных применений.

Hydra

  • Версия: 0.1.8.
  • Путь в дереве портов: www/hydra.
  • Размер архива: 275 Кб (от 21.06.2006).
  • Сайт разработчикаhttp://hydra.hellug.gr.

Высокопроизводительный (по определению разработчиков) многопоточный сервер.

Использует фиксированный пул заранее созданных потоков, каждый из которых за счёт мультиплексирования способен обрабатывать несколько запросов одновременно. Поддержка виртуального хостинга, HTTP/1.1, CGI, SSL.

В «прародителях» значится рассмотренный выше Boa.

В конфигурационном файле (несколько громоздком, но понятном) была раскомментирована поддержка CGI по типу:

AddType application/x-httpd-cgi cgi

Для работы с большими файлами нужно увеличить значение параметра MaxFileSizeCache.

Один процесс размером  3,6 Мб загружал на WART-тесте процессор в пределах 30-43%, показав производительность до 39 страниц в секунду (см. рис. 9 и таблицу 10).

Таблица 10. Hydra

Тест

1000/1

1000/10

1000/100

«Малый статик»

4.108

4.020

5.127

«Большой статик»

101.538

110.578

139.080

«Чистый CGI»

201.234

223.744

241.509

Рисунок 9. Hydra

Рисунок 9. Hydra

Вывод: ошибки при CGI-запросах и некоторый «провал» при большом числе конкурентных запросов немного портят впечатление, оставленное шикарным результатом WART-теста.

lighttpd

  • Версия: 1.4.13.
  • Путь в дереве портов: www/lighttpd.
  • Размер архива: 779 Кб (от 29.01.2007).
  • Сайт разработчикаhttp://www.lighttpd.net.

Функционально очень развитый веб-сервер, сохранивший легковесность и простоту работы.

Первое, на что натыкаешься в конфигурационном файле (etc/lighttpd.conf) – на список модулей, которые можно подгружать при старте сервера. Среди них – mod_rewrite, mod_redirect, mod_auth, mod_userdir, mod_cgi, mod_fastcgi, mod_proxy, mod_compress...  До Apache, пожалуй, не дотягивает, но данный набор с лихвой удовлетворит потребности подавляющего большинства пользователей.

Формат директив в etc/lighttpd.conf выглядит немного «нестандартно»:

server.document-root      = "/var/www"

cgi.assign                = ( ".pl"  => "/usr/bin/perl",

                              ".cgi" => "/usr/bin/perl" )

Нужно также открыть mod_cgi. При такой схеме в скриптах не должно быть строки «#!». Можно указать «'.cgi' => ''» – тогда CGI будет работать традиционно, запуская интерпретатор, указанный в строке «#!».

К сожалению, ни в том, ни в другом режиме, несмотря на «игры» с различными server.*-опциями, полноценно протестировать обработку CGI-страниц не удалось – спустя 200-300 запросов сервер без объявления ошибок переставал отвечать на запросы ab, нагрузка на процессор полностью падала. Тест завершался с сообщением «Server timed out». (При ограничении числа запросов до 100 были получены результаты 17,2 сек., 18,4 сек. и 35,3 сек. соответственно.)

В тесте WART достиг производительности 29 стр. в секунду, нагрузка на процессор при этом составляла 28-33% (см. рис. 10 и таблицу 11).

Таблица 11. lighttpd

Тест

1000/1

1000/10

1000/100

«Малый статик»

3.679

3.504

4.350

«Большой статик»

73.566

81.525

85.519

«Чистый CGI»

?

?

218.448

Рисунок 10. lighttpd

Рисунок 10. lighttpd

Вывод: cтатические тесты – выше всяких похвал. 1000 запросов на CGI-тестах почему-то оказались серверу не по силам (странно, что в одной из попыток удалось-таки получить значение в режиме 1000/100).

mathopd

  • Версия: 1.5p5.
  • Путь в дереве портов: www/mathopd.
  • Размер архива: 57 Кб (от 23.03.2005).
  • Сайт разработчикаhttp://www.mathopd.org.

Надеюсь, вам ещё не надоели «очень маленькие и производительные» веб-серверы с поддержкой CGI? Вот вам очередной представитель плеяды.

В конфигурации сразу подстраиваем значения в секции Tuning, влияющие на максимальную нагрузку. Попутно можно подправить пути к pid- и log-файлам, поставить «User www» вместо daemon – здесь многое нестандартно, по крайней мере, для FreeBSD. Поддерживается cgi, php (в секциях Specials и Externals соответственно), виртуальный хостинг, userdir, redirect.

На WART-тесте показал в среднем 32 страницы в секунду при 30%-ной загрузке процессора. Однако размер процесса mathopd – 197 Мб! – заставил усомниться в своём зрении и пару раз перезапустить top (см. рис. 11 и таблицу 12)...

Таблица 12. mathopd

Тест

1000/1

1000/10

1000/100

«Малый статик»

3.101

2.944

3.201

«Большой статик»

64.388

73.955

60.612

«Чистый CGI»

209.350

224.391

232.714

Рисунок 11. mathopd

Рисунок 11. mathopd

Вывод: низкая скорость обработки CGI-запросов с лихвой компенсируется отличными показателями при работе со статической нагрузкой.

micro_httpd

Ну что тут можно сказать? Много в 200 строк кода не затолкаешь. Тем не менее есть автоиндекс, поддержка MIME-типов (правда, в исходный код зашитая) и даже какие-то зачатки редиректа.

Из исходников собирается единственный двоичный файл, который следует запускать через inetd, указав в качестве параметра рабочий каталог сайта (как и в случае fnord).

WART-тест не порадовал – 20 страниц в секунду при 100%-ной загрузке процессора (см. рис. 12 и таблицу 13).

Таблица 13. micro_httpd

Тест

1000/1

1000/10

1000/100

«Малый статик»

30.898

31.951

33.459

«Большой статик»

180.177

189.469

215.069

«Чистый CGI»

Рисунок 12. micro_httpd

Рисунок 12. micro_httpd

Вывод: хотел было написать, что «мал, да удал», но нет... С такими скоростными показателями он имеет смысл разве что для изучения – в двухстах строках трудно заблудиться. Ну или в том случае, когда вам приходится беречь каждый килобайт дискового пространства.

mini_httpd

  • Версия: 1.19.
  • Путь в дереве портов: www/mini_httpd.
  • Размер архива: 41 Кб (от 29.06.2005).
  • Сайт разработчикаhttp://www.acme.com/software/mini_httpd.

Старший брат ранее рассмотренного micro_httpd, уже с поддержкой CGI, автоиндексом и некоторыми другими возможностями «больших мальчиков». Предварительно нужно подправить пути в конфигурационном файле sbin/mini_httpd_wrapper и добавить шаблон для CGI-сценариев:

/usr/local/mini_httpd/sbin/mini_httpd -D -c '**.cgi'

Вместо указания ключей можно параметры внести в конфигурационный файл (см. man mini_httpd).

Запуск по умолчанию выполняется из каталога веб-сервера:

wwwtest# cd /var/www

wwwtest# /usr/local/mini_httpd/sbin/mini_httpd_wrapper &

Интересная особенность – интерпретатор Perl для CGI-сценариев запускается со значением nice, равным 10, то есть все, кому не лень, будут его вытеснять. 37-38 страниц в секунду на WART-тесте (с редкими провалами до 30) сопровождаются нагрузкой на уровне 72-100%. Поэтому на локальных ab-тестах силёнок, видимо, и не хватило (см. рис. 13 и таблицу 14).

Таблица 14. mini_httpd

Тест

1000/1

1000/10

1000/100

«Малый статик»

13.903

14.100

16.505

«Большой статик»

69.209

68.941

64.830

«Чистый CGI»

186.052

202.774

228.614

Рисунок 13. mini_httpd

Рисунок 13. mini_httpd

Вывод: очень хорошие показатели на больших файлах (с ростом числа одновременных запросов даже наблюдается рост производительности), но на небольших файлах и CGI-запросах не впечатляет. На CGI-тесте при 1000/100 соединений проскочило 8 ошибок.

monkey

  • Версия: 0.9.1.
  • Путь в дереве портов: www/monkey.
  • Размер архива: 82 Кб (от 13.04.2005).
  • Сайт разработчикаhttp://monkeyd.sourceforge.net.

Написан на «чистом C», с поддержкой CGI и PHP, userdir, виртуального хостинга. Есть встроенная поддержка добавления к каждой веб-странице «шапки» и «подвала» (header и footer). В etc/monkey/ вы найдёте щедро прокомментированные конфигурационные файлы. Для тестирования были выставлены с запасом тайм-ауты и максимальное число клиентов. Параметр DocumentRoot здесь именуется Server_root.

Запуск/останов выполняются скриптом sbin/banana (а чем ещё можно заставить мартышку что-то делать?). При первой попытке запуска ругнулся на невозможность открыть файл monkey.mime (который вообще никуда не установился и о котором скудная документация упорно умалчивает). Пришлось его вручную перекидывать из установочного каталога conf/monkey.mime.

40-50% загрузки в WART-тесте позволяли первые 15-30 секунд работать с производительностью порядка 30 запросов в секунду, после чего сервер «падал». Хотя на локальных тестах его устойчивость была чуть выше (см. рис. 14 и таблицу 15).

Таблица 15. monkey

Тест

1000/1

1000/10

1000/100

«Малый статик»

5.618

5.577

9.351

«Большой статик»

129.180

134.481

241.984

«Чистый CGI»

191.860

190.631

207.245

Рисунок 14. monkey

Рисунок 14. monkey

Вывод: резкий провал в режиме 1000/100 и огромное число ошибок (в среднем по 150 на 1000 запросов) плюс аварийные завершения работы в CGI-тестах смещают этот сервер на роль слабозагруженного «поставщика» чисто статических файлов. Да и то не самого быстрого.

nginx

  • Версия: 0.5.10.
  • Путь в дереве портов: www/nginx.
  • Размер архива: 444 Кб (от 25.01.2007).
  • Сайт разработчикаhttp://sysoev.ru/nginx.

Результат работы нашего соотечественника Игоря Сысоева. Неплохой функционал, поддержка FastCGI, SSL, свыше десятка различных модулей делают его хорошим выбором. Особую известность nginx получил как веб-акселератор.

Поддержки «чистого CGI» в нём я не нашёл (есть встроенный интерпретатор Perl, но его использование было бы несправедливым по отношению к другим рассматриваемым серверам), поэтому CGI-тест для него не выполнялся.

Непривычный, но удобный в работе «Си-подобный» формат конфигурационного файла. Например, так задаётся корневой каталог:

location / {

    root   /var/www;

    index  index.html index.htm;

}

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

При одном из самых низких показателей загрузки процессора – 20-25% – на WART-тесте продемонстрировал средний результат в районе 25 запросов в секунду (см. рис. 15 и таблицу 16).

Таблица 16. nginx

Тест

1000/1

1000/10

1000/100

«Малый статик»

3.284

3.280

3.843

«Большой статик»

70.949

64.262

58.345

«Чистый CGI»

Рисунок 15. nginx

Рисунок 15. nginx

Справедливости ради отмечу, что с выставлением в конфигурации параметра «worker_processes» на уровне 10 вместо используемого по умолчанию значения 1 достигается производительность 46 запросов в секунду при загрузке процессора на уровне 50% (см. рис. 16). Однако мы договорились не углубляться в тонкую настройку.

Рисунок 16. ginx при 10 процессах

Рисунок 16. ginx при 10 процессах

Вывод: одни из лучших показателей производительности на «статике». Вкупе со множеством других функций – хороший претендент на замену Apache для решения типовых задач.

pserv

  • Версия: 3.3.
  • Путь в дереве портов: www/pserv.
  • Размер архива: 102 Кб (от 16.05.2005).
  • Сайт разработчикаhttp://sourceforge.net/projects/pserv.

В основу этого сервера положена идея портируемости (хотя на Windows она не распространилась). Конфигурация после громоздких «больших» серверов – как бальзам на душу. Буквально 10 строк. Для выполнения нагрузочных тестов нужно увеличить там значения тайм-аутов (однако чрезмерное увеличение uSecTimeout приводит к ошибкам «setsockopt: : Numerical argument out of domain», а недостаточное значение приводит к ошибкам тестов при большой параллельности). К сожалению, способа запустить pserv как демон я не нашёл, поэтому пришлось избавляться от отладочных сообщений путём перенаправления их в /dev/null:

AddType application/x-httpd-cgi cgi

На WART-тесте нагрузка на процессор «плавала» в районе 70-100%, но при этом получить какой-нибудь результат, как и в случае с fnord, не удалось – отчёты упорно выдавали одни нули и на HTTP/1.1, и на HTTP/1.0 (см. таблицу 17).

Таблица 17. pserv

Тест

1000/1

1000/10

1000/100

«Малый статик»

13.702

13.008

15.004

«Большой статик»

135.663

156.336

150.127

«Чистый CGI»

208.115

220.721

183.227

Вывод: снижение времени теста в режиме 1000/100 «Большого статика» и CGI-теста обусловлено появлением 997 и 282 ошибок соответственно – такая нагрузка, похоже, серверу не по силам.

shttpd

  • Версия: 1.35.
  • Путь в дереве портов: www/shttpd.
  • Размер архива: 47 Кб (от 07.04.2006).
  • Сайт разработчикаhttp://shttpd.sourceforge.net.

Поддерживает SSI, CGI, SSL, виртуальные домены, userdir, ограничения скорости. Позиционируется прежде всего как простой и не требующий установки веб-сервер для целей тестирования для систем Windows, однако и в UNIX чувствует себя не хуже. Запускается из командной строки:

wwwtest# bin/shttpd -d /var/www -c cgi -p 80 -u www &

Процессор на WART-тесте он нагрузил почти на две трети (55-70%), выдав близкое к рекорду значение производительности – 44 страницы в секунду. Правда, на локальных тестах «запаса прочности» не хватило (см. рис. 17 и таблицу 18).

Таблица 18. shttpd

Тест

1000/1

1000/10

1000/100

«Малый статик»

5.743

5.271

7.046

«Большой статик»

144.175

226.484

219.082

«Чистый CGI»

183.127

189.647

185.757

Рисунок 17. shttpd

Рисунок 17. shttpd

Вывод: неплохая скорость обслуживания CGI-запросов при средних показателях на «статике». Но для веб-разработчиков может оказаться весьма удобным.

thttpd

  • Версия: 2.25b.
  • Путь в дереве портов: www/thttpd.
  • Размер архива: 129 Кб (от 29.06.2005).
  • Сайт разработчикаhttp://www.acme.com/software/thttpd.

Простой шестистрочный конфигурационный файл, а также возможность задавать все опции в командной строке... Поддержка CGI и HTTP/1.1. Как и его братья (mini_httpd и micro_httpd), делает что-то непотребное с русским текстом в UTF-8.

Зато на WART – абсолютный рекорд в 49 страниц в секунду при загрузке процессора на уровне 39-51% (см. рис. 18 и таблицу 19).

Таблица 19. thttpd

Тест

1000/1

1000/10

1000/100

«Малый статик»

3.739

3.179

3.473

«Большой статик»

64.832

56.909

54.067

«Чистый CGI»

186.802

195.754

233.423

Рисунок 18. thttpd

Рисунок 18. thttpd

Вывод: хорош на статике, но CGI обрабатывает не слишком быстро. К тому же, было отмечено 11 ошибок в режиме 1000/100 CGI-теста. Тем не менее именно этот сервер предпочитают разработчики встроенных систем (например, многих ADSL-модемов).

wyvern

Очень порадовала документация на японском на страничке, открывающейся по умолчанию, – несколько секунд провёл в созерцании иероглифов. Вся конфигурация – в /conf. Прокомментирован конфиг хорошо, похож на httpd.conf сервера Apache. Есть семь уровней безопасности с разными ограничениями, userdir, автоиндекс, поддержка символических ссылок, CGI, модули, виртуальный хостинг... Выглядит неплохо.

Чтобы работала поддержка CGI с переменными окружения, нужно раскомментировать следующие модули:

Module  modules/mod_env.so

Module  modules/mod_cgi.so

В среднем 45 запросов в секунду в WART-тесте при загрузке процессора до 59%. Но проскакивали ошибки. На CGI-тесте произошло что-то страшное (см. рис. 19 и таблицу 20)...

Таблица 20. wyvern

Тест

1000/1

1000/10

1000/100

«Малый статик»

4.558

4.793

6.329

«Большой статик»

120.369

124.180

168.180

«Чистый CGI»

329.094

fail

fail

Рисунок 19. wyvern

Рисунок 19. wyvern

Вывод: 218 ошибок на «большом статике» в режиме 1000/100. Плюс к этому самая медленная обработка CGI «по одному» и паталогическая неспособность обслуживать CGI-запросы параллельно.

xitami

  • Версия: 2.5c2.
  • Путь в дереве портов: www/xitami.
  • Размер архива: 1815 Кб (от 22.07.2004).
  • Сайт разработчикаhttp://www.xitami.com.

Пожалуй, самый невзрачный веб-сервер: не маленький, не быстрый, не слишком функциональный, не особенно документированный... Процессор загрузил не сильно, показав не ахти какую производительность на WART-тесте (см. рис. 19 и таблицу 20)... Я затрудняюсь сказать, почему его следовало бы использовать.

Таблица 21. xitami

Тест

1000/1

1000/10

1000/100

«Малый статик»

7.603

7.413

11.648

«Большой статик»

242.929

236.415

243.825

«Чистый CGI»

238.035

207.032

188.908

Рисунок 20. xitami

Рисунок 20. xitami

Вывод: медленный, плюс ошибки во всех тестах в режиме 1000/100 (видимо, сервер борется с нагрузкой, отбрасывая «лишние» запросы).

xshttpd

  • Версия: 3.3.g01_1.
  • Путь в дереве портов: www/xshttpd.
  • Размер архива: 203 Кб (от 06.11.2005).
  • Сайт разработчикаhttp://www.stack.nl/xs-httpd.

Как заявлено на сайте, не просто маленький и быстрый, а маленький и быстрый! Есть поддержка CGI, сжатия. При старте запускает указанное в конфигурации число процессов, которые в дальнейшем за всё и «отдуваются». При компиляции можно включить опцию «Persistent Perl», но я её не тестировал.

При загрузке процессора на 52-71% показал производительность 30-35 страниц в секунду, хотя на «локальных» тестах производительности был слаб (см. рис. 20 и таблицу 21).

Таблица 22. xshttpd

Тест

1000/1

1000/10

1000/100

«Малый статик»

9.474

8.967

9.096

«Большой статик»

126.493

127.753

141.032

«Чистый CGI»

265.402

194.916

176.747

Рисунок 21. xshttpd

Рисунок 21. xshttpd

Вывод: не обольщайтесь снижением времени выполнения CGI-тестов с ростом нагрузки – это результат 106 ошибок. Также ошибки были и на «большом статике» в режиме 1000/100.

zerowait-httpd

  • Версия: 0.7p.
  • Путь в дереве портов: www/zerowait-httpd.
  • Размер архива: 97 Кб (от 18.11.2006).
  • Сайт разработчикаhttp://www.0w.ru/httpd.

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

На WART-тесте при загрузке 25-40% отдавал страницы со скоростью около 35 штук в секунду. На локальных тестах был просто блестящ (см. рис. 21 и таблицу 22).

Таблица 23. zerowait_httpd

Тест

1000/1

1000/10

1000/100

«Малый статик»

2.983

3.868

3.713

«Большой статик»

66.278

56.912

50.554

«Чистый CGI»

Рисунок 22. zerowait_httpd

Рисунок 22. zerowait_httpd

Вывод: что ж, имя своё этот сервер получил не зря. Особенно впечатляет рост производительности с ростом нагрузки.

Подведение итогов

Что же, если говорить о работе со статическими файлами, то у Apache много конкурентов, делающих это быстрее и экономнее по отношению к ресурсам. Это и Cherokee, и gatling, и hydra, и mathopd (несмотря на ужасающий размер процесса), и nginx, и thttpd, и zerowait_httpd. Если требуется хотя бы базовая поддержка CGI, число конкурентов несколько снижается, но альтернативы по-прежнему есть.

Понятно, что от веб-сервера требуется не только скорость. Функциональность и работа с динамическим контентом в наши дни приобретают всё большее значение. Впрочем, работа с FastCGI, PHP и т. д. заслуживает отдельного обзора.

А на сегодня нашу работу будем считать завершённой. Основные характеристики рассмотренных веб-серверов вынесены в сводную таблицу (cм. таблицу 24).

Таблица 24. Сводная таблица

 

Размер дистрибутива

Время сборки/установки

Т1*

Т2*

Т3*

T4*

%*

Размер процесса в памяти

Поддержка FastCGI и/или PHP

Поддержка виртуального хостинга

Поддержка «автоиндексации» каталога

Apache 13

2,6 Мб

5 м

4,6

112,9

185,2

44

60

2,6 Мб

+

+

+

Apache 22

4,8 Мб

34 м

5,1

61,3

190,4

37

45

6,4 Мб

+

+

+

Boa

163 Кб

2 м

3,7

150,6

181,1

35

37

1,4 Мб

+

+

bozohttpd

32 Кб

20 с

16,5

117,0

198,0

25

99

2,5 Мб

+

+

Cherokee

1,3 Мб

3 м

3,9

79,8

205,8

25

30

4,5 Мб

+

+

+

DFileServer

22 Кб

2 м

4,3

132,9

27

70

2,3 Мб

+

fnord

32 Кб

30 с

29,7

133,9

?

?

1,3 Мб

+

+

gatling

60 Кб

30 с

2,7

52,2

?

25

23

1,5 Мб

+

+

hiawatha

180 Кб

2 м

5,7

118,9

192,1

30

40

6,3 Мб

+

+

Hydra

275 Кб

3 м

4,0

110,6

223,7

39

37

3,6 Мб

+

+

lighttpd

779 Кб

10 м

3,5

81,5

?

29

31

2,9 Мб

+

+

+

mathopd

57 Кб

20 с

2,9

74,0

224,4

32

30

197 Мб

+

+

micro_httpd

5 Кб

5 с

32,0

189,5

20

99

1,2 Мб

+

mini_httpd

41 Кб

20 с

14,1

68,9

202,8

38

90

2,6 Мб

+

monkey

82 Кб

25 с

5,6

134,5

190,6

?

?

4,8 Мб

+

+

+

nginx

444 Кб

3 м

3,3

64,3

25

23

2,2 Мб

+

+

pserv

102 Кб

1 м

13,0

156,3

220,7

?

?

1,3 Мб

+

shttpd

47 Кб

20 с

5,3

226,5

189,6

44

65

1,6 Мб

+

wyvern

415 Кб

3 м

4,8

124,2

fail

45

59

2,7 Мб

+

+

xitami

1,8 Мб

5 м

7,4

236,4

207,0

24

36

5,2 Мб

+

xshttpd

203 Кб

2 м

9,0

127,8

194,9

33

60

2,8 Мб

+

zerowait_httpd

97 Кб

1 м

3,9

56,9

35

35

1,8 Мб

Удачных вам выборов!


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru