 |
|
|
|
Большие гонки веб-серверов
Большие гонки веб-серверов Современная жизнь немыслима без Интернета, а Интернету необходимы веб-серверы. Смутное подозрение, что 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
Про Apache, думаю, слышал каждый – это самый распространённый веб-сервер, широко используемый на различных задачах от «тестовой» инсталляции на домашней машине для отладки разрабатываемых PHP-сценариев до самых посещаемых порталов, ежесекундно отправляющих в Интернет гигабайты информации. Любят Apache прежде всего за его устойчивость, гибкость, функциональность и хорошую документированность. Настройка не самая простая (хотя о какой простоте может идти речь при такой функциональности?), но благодаря хорошей документации и широкой поддержке сообщества это обычно не является проблемой. В WART-тесте после небольшой «раскачки» была продемонстрирована скорость обработки запросов на уровне 44 страницы в секунду при загрузке процессора примерно на 60% (см. рис. 1 и таблицу 1). Таблица 1. Apache 1.3
Рисунок 1. Apache 1.3 Вывод: тесты показали очень высокую устойчивость к нагрузкам – число одновременных запросов практически не влияло на общее время выполнения тестов. Ошибок не наблюдалось. Производительность – одна из самых высоких. Apache 2.2
Вторая версия Apache. Основное отличие от версии 1.3 – переход к «многопоточной» архитектуре, когда один процесс может одновременно обслуживать несколько запросов. На редкость долгая сборка – 34 минуты. Разбираться не стал (собралось, и ладно), но неприятный осадок остался. В конфигурации нужно не забыть открыть (в секции <Directory />) доступ как минимум с хоста, откуда выполняется тестирование – по умолчанию там стоит «Deny from all». Единственный веб-сервер, загнавший при выполнении тестов значение «Load average» аж до 110. Для FreeBSD это ощутимо. В WART-тесте, тоже после «раскачки», достиг 37 запросов в секунду, нагружая процессор на 40-45% (см. рис. 2 и таблицу 2). Таблица 2. Apache 2.2
Рисунок 2. Apache 2.2 Увеличив в конфигурации максимальное число процессов, можно поднять это значение до 42-43 запросов при загрузке процессора порядка 60%. На ab-тестах, учитывая полную загрузку процессора, такая подстройка не оказывала заметного влияния. Вывод: эта версия также продемонстрировала устойчивость к нагрузкам (при 10 конкурирующих запросах даже наблюдается рост производительности). По сравнению с Apache 1.3 заметно улучшилась работа с большими файлами, в остальном производительность несколько снизилась. Дополнительной подстройкой применительно к конкретной системе эти результаты могут быть ещё несколько улучшены (равно как и ухудшены), однако это уже тема для отдельной статьи. Boa
Основной конфигурационный файл 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
Рисунок 3. Boa Вывод: на малых статических файлах обходит Apache 1.3 почти на 25%, ненамного отставая на других тестах. С ростом числа параллельных запросов производительность падает. 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
Рисунок 4. bozohttpd Вывод: что-то страшное на небольших файлах (видимо, высока стоимость создания нового процесса). Также заметно «проседание» под нагрузкой. Для больших файлов и CGI не так плохо, но и до рекорда ещё ой как далеко. Cherokee
Заявлен как быстрый, гибкий и простой в настройке веб-сервер с поддержкой 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
Рисунок 5. Cherokee Вывод: несмотря на «проседание» при большом числе одновременных запросов, по скорости составляет серьёзную конкуренцию обоим «Апачам» при заметно меньшей нагрузке на процессор. DFileServer
Странный проект. Первое, что бросилось в глаза – отсутствие какой-либо документации, инсталлируемой вместе с сервером. Попытка запустить «в лоб» приводила лишь к старту на 2000-м порту в текущем каталоге. Как выяснилось из скудной документации, которую можно найти в исходниках, порт указывается в параметре -port, а рабочим каталогом станет текущий. Так что запуск выполнялся таким образом: wwwtest# cd /var/www wwwtest# /usr/local/dfileserver/bin/dfileserver -port 80 & В среднем 27 страниц в секунду при загрузке процессора от 30 до 80%. Пару раз на WART-тесте отмечалось падение производительности до нуля (см. рис. 6 и таблицу 6). Таблица 6. DFileServer
Рисунок 6. DFileServer Вывод: неплохие скоростные показатели (CGI сервером не поддерживается). Учитывая небольшой размер и простоту, вполне может сгодиться для быстрого запуска чего-нибудь статического. Например, чтобы с любого компьютера в сети можно было читать html-документацию к Apache. 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
Вывод: что ещё можно было ожидать от запуска через inetd? Но зато в «демонах» постоянно не болтается... 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
Рисунок 7. gatling Вывод: серьёзная заявка на рекорд, особенно при 10 одновременных запросах, однако 5 ошибок в тестах 1000/100 несколько портят впечатление. Также осталась непонятной ситуация с CGI. hiawatha
Основной особенностью этого сервера заявлена безопасность. Apache на официальном сайте назван «большой жирной коровой», хотя, забегая вперёд, скажу, что такая самонадеянность разработчиков выглядит несколько беспочвенной. Конфигурация располагается в etc/hiawatha, основной файл – httpd.conf. Для работы с CGI-сценариями на Perl нужно раскомментировать обработчик: CGIhandler = /usr/bin/perl:cgi Причём cgi-скрипт не должен содержать строки «#!» – почему-то на ней возникала ошибка. Для каждого языка сценариев нужно прописывать свой обработчик. Плавающая в пределах 30-50% загрузка процессора на WART-тесте при 30 страницах – не самый лучший результат. Даже в сравнении с «большой жирной коровой» (см. рис. 8 и таблицу 9). Таблица 9. hiawatha
Рисунок 8. hiawatha Вывод: в общей сложности 40 ошибок (а это почти 0,5% от общего числа запросов) заставляет относиться к серверу с настороженностью. «Провал» в режиме 1000/100 на статических запросах также опускает этот сервер в область слабонагруженных применений. Hydra
Высокопроизводительный (по определению разработчиков) многопоточный сервер. Использует фиксированный пул заранее созданных потоков, каждый из которых за счёт мультиплексирования способен обрабатывать несколько запросов одновременно. Поддержка виртуального хостинга, HTTP/1.1, CGI, SSL. В «прародителях» значится рассмотренный выше Boa. В конфигурационном файле (несколько громоздком, но понятном) была раскомментирована поддержка CGI по типу: AddType application/x-httpd-cgi cgi Для работы с большими файлами нужно увеличить значение параметра MaxFileSizeCache. Один процесс размером 3,6 Мб загружал на WART-тесте процессор в пределах 30-43%, показав производительность до 39 страниц в секунду (см. рис. 9 и таблицу 10). Таблица 10. Hydra
Рисунок 9. Hydra Вывод: ошибки при CGI-запросах и некоторый «провал» при большом числе конкурентных запросов немного портят впечатление, оставленное шикарным результатом WART-теста. lighttpd
Функционально очень развитый веб-сервер, сохранивший легковесность и простоту работы. Первое, на что натыкаешься в конфигурационном файле (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
Рисунок 10. lighttpd Вывод: cтатические тесты – выше всяких похвал. 1000 запросов на CGI-тестах почему-то оказались серверу не по силам (странно, что в одной из попыток удалось-таки получить значение в режиме 1000/100). mathopd
Надеюсь, вам ещё не надоели «очень маленькие и производительные» веб-серверы с поддержкой CGI? Вот вам очередной представитель плеяды. В конфигурации сразу подстраиваем значения в секции Tuning, влияющие на максимальную нагрузку. Попутно можно подправить пути к pid- и log-файлам, поставить «User www» вместо daemon – здесь многое нестандартно, по крайней мере, для FreeBSD. Поддерживается cgi, php (в секциях Specials и Externals соответственно), виртуальный хостинг, userdir, redirect. На WART-тесте показал в среднем 32 страницы в секунду при 30%-ной загрузке процессора. Однако размер процесса mathopd – 197 Мб! – заставил усомниться в своём зрении и пару раз перезапустить top (см. рис. 11 и таблицу 12)... Таблица 12. mathopd
Рисунок 11. mathopd Вывод: низкая скорость обработки CGI-запросов с лихвой компенсируется отличными показателями при работе со статической нагрузкой. micro_httpd
Ну что тут можно сказать? Много в 200 строк кода не затолкаешь. Тем не менее есть автоиндекс, поддержка MIME-типов (правда, в исходный код зашитая) и даже какие-то зачатки редиректа. Из исходников собирается единственный двоичный файл, который следует запускать через inetd, указав в качестве параметра рабочий каталог сайта (как и в случае fnord). WART-тест не порадовал – 20 страниц в секунду при 100%-ной загрузке процессора (см. рис. 12 и таблицу 13). Таблица 13. micro_httpd
Рисунок 12. micro_httpd Вывод: хотел было написать, что «мал, да удал», но нет... С такими скоростными показателями он имеет смысл разве что для изучения – в двухстах строках трудно заблудиться. Ну или в том случае, когда вам приходится беречь каждый килобайт дискового пространства. 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
Рисунок 13. mini_httpd Вывод: очень хорошие показатели на больших файлах (с ростом числа одновременных запросов даже наблюдается рост производительности), но на небольших файлах и CGI-запросах не впечатляет. На CGI-тесте при 1000/100 соединений проскочило 8 ошибок. monkey
Написан на «чистом 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
Рисунок 14. monkey Вывод: резкий провал в режиме 1000/100 и огромное число ошибок (в среднем по 150 на 1000 запросов) плюс аварийные завершения работы в CGI-тестах смещают этот сервер на роль слабозагруженного «поставщика» чисто статических файлов. Да и то не самого быстрого. nginx
Результат работы нашего соотечественника Игоря Сысоева. Неплохой функционал, поддержка FastCGI, SSL, свыше десятка различных модулей делают его хорошим выбором. Особую известность nginx получил как веб-акселератор. Поддержки «чистого CGI» в нём я не нашёл (есть встроенный интерпретатор Perl, но его использование было бы несправедливым по отношению к другим рассматриваемым серверам), поэтому CGI-тест для него не выполнялся. Непривычный, но удобный в работе «Си-подобный» формат конфигурационного файла. Например, так задаётся корневой каталог: location / { root /var/www; index index.html index.htm; } Работает в рамках одного процесса (точнее, в конфигурации можно задать число «детей», но я решил все серверы тестировать с настройками по умолчанию, изменяя лишь некоторые ограничения да корневой каталог сайта). При одном из самых низких показателей загрузки процессора – 20-25% – на WART-тесте продемонстрировал средний результат в районе 25 запросов в секунду (см. рис. 15 и таблицу 16). Таблица 16. nginx
Рисунок 15. nginx Справедливости ради отмечу, что с выставлением в конфигурации параметра «worker_processes» на уровне 10 вместо используемого по умолчанию значения 1 достигается производительность 46 запросов в секунду при загрузке процессора на уровне 50% (см. рис. 16). Однако мы договорились не углубляться в тонкую настройку.
Рисунок 16. ginx при 10 процессах Вывод: одни из лучших показателей производительности на «статике». Вкупе со множеством других функций – хороший претендент на замену Apache для решения типовых задач. 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/100 «Большого статика» и CGI-теста обусловлено появлением 997 и 282 ошибок соответственно – такая нагрузка, похоже, серверу не по силам. shttpd
Поддерживает 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
Рисунок 17. shttpd Вывод: неплохая скорость обслуживания CGI-запросов при средних показателях на «статике». Но для веб-разработчиков может оказаться весьма удобным. thttpd
Простой шестистрочный конфигурационный файл, а также возможность задавать все опции в командной строке... Поддержка CGI и HTTP/1.1. Как и его братья (mini_httpd и micro_httpd), делает что-то непотребное с русским текстом в UTF-8. Зато на WART – абсолютный рекорд в 49 страниц в секунду при загрузке процессора на уровне 39-51% (см. рис. 18 и таблицу 19). Таблица 19. 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
Рисунок 19. wyvern Вывод: 218 ошибок на «большом статике» в режиме 1000/100. Плюс к этому самая медленная обработка CGI «по одному» и паталогическая неспособность обслуживать CGI-запросы параллельно. xitami
Пожалуй, самый невзрачный веб-сервер: не маленький, не быстрый, не слишком функциональный, не особенно документированный... Процессор загрузил не сильно, показав не ахти какую производительность на WART-тесте (см. рис. 19 и таблицу 20)... Я затрудняюсь сказать, почему его следовало бы использовать. Таблица 21. xitami
Рисунок 20. xitami Вывод: медленный, плюс ошибки во всех тестах в режиме 1000/100 (видимо, сервер борется с нагрузкой, отбрасывая «лишние» запросы). xshttpd
Как заявлено на сайте, не просто маленький и быстрый, а маленький и быстрый! Есть поддержка CGI, сжатия. При старте запускает указанное в конфигурации число процессов, которые в дальнейшем за всё и «отдуваются». При компиляции можно включить опцию «Persistent Perl», но я её не тестировал. При загрузке процессора на 52-71% показал производительность 30-35 страниц в секунду, хотя на «локальных» тестах производительности был слаб (см. рис. 20 и таблицу 21). Таблица 22. xshttpd
Рисунок 21. xshttpd Вывод: не обольщайтесь снижением времени выполнения CGI-тестов с ростом нагрузки – это результат 106 ошибок. Также ошибки были и на «большом статике» в режиме 1000/100. zerowait-httpd
На домашней странице на чистейшем русском сообщается, что этот сервер предназначен для быстрой и незатратной с точки зрения ресурсов выдачи статического контента и годится, таким образом, для развёртывания статических сайтов и на роль веб-акселератора. На WART-тесте при загрузке 25-40% отдавал страницы со скоростью около 35 штук в секунду. На локальных тестах был просто блестящ (см. рис. 21 и таблицу 22). Таблица 23. zerowait_httpd
Рисунок 22. zerowait_httpd Вывод: что ж, имя своё этот сервер получил не зря. Особенно впечатляет рост производительности с ростом нагрузки. Подведение итогов Что же, если говорить о работе со статическими файлами, то у Apache много конкурентов, делающих это быстрее и экономнее по отношению к ресурсам. Это и Cherokee, и gatling, и hydra, и mathopd (несмотря на ужасающий размер процесса), и nginx, и thttpd, и zerowait_httpd. Если требуется хотя бы базовая поддержка CGI, число конкурентов несколько снижается, но альтернативы по-прежнему есть. Понятно, что от веб-сервера требуется не только скорость. Функциональность и работа с динамическим контентом в наши дни приобретают всё большее значение. Впрочем, работа с FastCGI, PHP и т. д. заслуживает отдельного обзора. А на сегодня нашу работу будем считать завершённой. Основные характеристики рассмотренных веб-серверов вынесены в сводную таблицу (cм. таблицу 24). Таблица 24. Сводная таблица
Удачных вам выборов! |
Сергей Супрунов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
