Кто на свете всех быстрее

...или PHP vs Perl vs Mod_Perl vs JSP vs ASP.

Довольно часто в той или иной периодике я встречаю обзоры или результаты тестирования различного «железа», в то время как обзоры ПО и встречаются по реже и, как правило, ограничиваются субъективными оценками. Тем не менее, практически любая работа никогда не замыкается только на железо, и неминуемо включает в себя обращение к той «прослойке» между аппаратной составляющей и пользователем, которую принято называть программным обеспечением. И хотя иногда производители и независимые эксперты приводят количественные характеристики своих творений [1], все-таки порой эта информация исходит от заинтересованных сторон и требует некоторой перепроверки. К тому же, практически всегда, интерпретация результатов тестирования носит несколько однобокий характер и часто выглядит как «выпячивание» достоинств собственной технологии. Данная статья посвящена сравнению производительности нескольких, наиболее популярных серверных языков вкупе с веб-серверами, обеспечивающими их работу (данную связку: интерпретатор на стороне сервера и собственно сервер в дальнейшем мы будем называть серверной технологией — СТ).

Используемые технологии

• Resin 1.1 b2 (internal web server)
• Orion 0.7.6b (internal web server)
• Tomcat (internal web server)
• Resin 1.1 b2/Apache 1.3.9
• mod_php 4.0b2
• mod_perl 1.21
• JRun 2.3.3/Apache 1.3.9
• ServletExec 2.2/Apache 1.3.9
• CGI using Perl

Аппаратное и программное обеспечение

Сервер — 300 Mhz Pentium II, RedHat 6.0 / 64 Мб оперативной памяти.

Клиент — 300 Mhz Celeron, RedHat 6.0 / 32 Мб оперативной памяти.

Компьютеры соединялись с помощью 100bT Ethernet.

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

Везде, где не указано иное, в качестве веб сервера использовался Apache версия 1.3.9, все модули которого компилировались с поддержкой DSO.

Для теста обращения к базе данных использовался сервер MySQL с mm.mysql JDBC драйвером.

Используемые тесты (исходные тексты тестов прилагаются)

File. В данном тесте производилось чтение и передача небольшого (311 байт) статичного файла — т.е. тестирования СТ в качестве обычного веб-сервера.

Servlet. Для измерения «накладных расходов» работы СТ использовалась тестовая программа "Hello, World". Другими словами, как бы эффективно ни была написана ваша серверная программа, вы никогда не получите более высокие показатели производительности, нежели в этом тесте.

Hello. Тест, практически во все аналогичный тесту Servlet, с тем отличием, что применялся для тестирования PHP, Perl`a и ASP, тогда как Servlet относился лишь к Java СТ.

Loop. Тест выводящий "Hello, World" в цикле суммарным объемом около 64 кб. Этот тест, особенно в сравнении с тестом Big дает довольно грубое представление о производительности базовых функций.

Big. В данном тесте производилась отправка сравнительно большого (около 64 кб) массива статичной информации.

DB. Простейший запрос к базе данных (два запроса Select). Дает оценочное представление о производительности цепочки веб-сервер — СТ — сервер базы данных (точнее драйвер базы данных — сервер базы данных, даже если драйвер встроенный). Для JAVA тестов во второй части, первое число в таблице означает результаты тестирования с использованием драйвера org.gjt MySql. Второе число — результат тестирования с применением драйвера Caucho. В общем случае данный метод двойного тестирования демонстрирует важность драйвера базы данных для быстродействия системы в целом.

Cache. Тот же тест что и DB, но в заголовке страницы указывался «срок давности» (Expires) плюс 15 секунд от времени исполнения.

Перед каждым тестом клиент посылал единичный запрос к серверу, для минимизации влияния стартовых временных и ресурсных затрат. При тестировании клиент последовательно отсылает 1000 запросов, при этом каждый следующий запрос отсылается только после получения ответа на предыдущий. Каждый тест повторяется трижды, как результат засчитывается средний показатель. Там где это возможно в тестах использовался IBM 1.1.8 JDK. Там где данный JDK, по тем или иным причинам не применим или не работоспособен вместо IBM JDK использовали Blackdown 1.2, например для Orion использовали JDK 1.2, тогда как для JRun — IBM JDK.

Таблица производительности СТ — операций в секунду. Более высокие показатели означают большую производительность.

Интерпретация результатов

Практически во всех тестах безусловным лидером является Resin/IBM, отчасти благодаря встроенному веб-серверу, отчасти некоторой «заточенности» данной СТ именно под высокую скорость исполнения. Собственно первую причину подтверждают несколько худшие результаты Resin/Apache/IBM, где вместо специализированного используется универсальный веб-сервер. Mod_php и Mod_perl идут практически вровень, попеременно от теста к тесту меняясь местами, за исключением теста "Big" где Mod_php откровенно провалился, показав почти вдвое меньшую производительность. CGI perl, как и ожидалось, значительно отстал во всех тестах, кроме "File", где дело касалось лишь веб-сервера и он показал результат аналогичный Mod_perl/Apache.

Часть II

Данные тестовые испытания проводились по несколько другой схеме, исходными остались аппаратная платформа и сетевая инфраструктура, к исследуемым СТ добавлен ASP, (но ввиду некоторых проблем при обращении к серверу MySQL данный тест для ASP не проводился), модифицирована клиентская программа — для эмуляции «одновременной работы нескольких пользователей», некоторой внутренней модификации подверглись и сами тесты но их суть их осталась прежней.

Новые испытания проводились в два захода: в первом работа проходила, как и в предыдущем случае, один на один: один клиент — один сервер. Много интереснее вторая таблица где представлена ситуация четыре клиента — один сервер. Причем клиентская программа была специально модифицирована так, чтобы веб-сервер запускал «одновременно» четыре потока. Почему именно четыре? Учитывая малое время выполнения одного теста, одновременное выполнение четырех запросов представляется (по крайней мере, на мой взгляд) вполне достаточным и отражает загрузку небольшого по вселенским и среднепосещаемого, по российским меркам, сервера. (Предположительно около 20000 запросов в течение суток, 50% которых приходится на обед) — получаем пиковую загрузку порядка 10000 запросов в час, или 2,8 запроса в секунду. Даже учитывая, что запрос обрабатывается (не передается, а именно выполняется) сервером за секунду (что на самом деле есть преувеличение) получатся, что четыре запроса одновременно это очень хорошая загрузка).

Тест «Один пользователь». Данные в таблице представляют количество операций в секунду, чем выше показатель, тем выше производительность.

Тест «Четыре пользователя». Показатели в таблице представляют суммарную производительность, т.е. общее количество операций выполненных для всех четырех клиентов сервером. Программа клиент в запросе указывала запрос на включение режима keepalive протокола HTTP/1.1. Четвертый запрос закрывает соединение.

Некоторые размышления по поводу результатов

Несмотря на простоту используемых тестов они, тем не менее, вполне годятся для грубой оценки, тогда как полноценное тестовое приложение поставило бы больше вопросов, чем ответов. В первую очередь это связано с отсутствием даже не общепризнанных стандартов для тестирования СТ, а сколь-нибудь репрезентативной информации о приоритетах программистов (будь-то скорость выполнения, модульность или малая требовательность к объему памяти — а ведь все это практически взаимоисключающие приоритеты). До сих пор нет (или по крайней мере мне не попадалась на глаза) хоть какой-то статистики по структуре используемых программ. Именно по этим причинам в виде тестов использовались столь примитивные скрипты, к тому же у этого подхода есть ряд преимуществ. Например, тесты "Big" и "Loop" должны в результате своей работы сгенерировать примерно одинаковый объем данных, тогда как разница в показателях, для некоторых СТ, довольно разительна, что должно наводить на размышления.

Теперь собственно разбор результатов. С одной стороны созданные условия позволяли оценить чистую производительность СТ благодаря созданным тепличным условиям т.к. тестовые программы это единственное, что выполняли сервер и клиент. С другой тестирование проводилось для выяснения производительности всего комплекса, а не только интерпретатора. Это привело к тому, что лидером оказался Resin/JDK (во многом благодаря встроенному веб-серверу, по своей сути быстрому, но куцему по возможностям, с другой стороны и сама технология сервлетов сказывается — для данных тестовых скриптов тезис «память в обмен на производительность» актуален). Радует, что превосходство не распространяется на базы данных — доступ к ним из PHP и Perl как правило быстрее чем из их Java оппонентов. В принципе это означает, что в текущих реализациях JDBC драйверов еще есть возможности для оптимизации, а сам Java тут не причем, что подтверждают высокие показатели демонстрируемые при использовании Caucho.

Также заслуживает внимания динамика изменения производительности СТ при росте числе обращений. Perl при росте всех показателей продемонстрировал некоторый провал при обращении к базе данных — общая производительность вообще упала, тогда как для PHP, отмечается хоть и небольшой, но все же рост. Таким образом, PHP берет верх при файловых операциях и при работе с базами данных. Perl лидирует при обращении к большому объему информации с небольшим объемом собственно вычислений — (тест Big это в основном отправка данных в выходной поток). И Perl и PHP идут практически вровень при выполнении теста Loop, что означает примерно одинаковые показатели скорости выполнения простейшего скрипта.

Теперь «разберемся» с ASP. Мощно начав на тесте "File", и опередив все СТ, продукт Microsoft в дальнейшем не показал ничего выдающегося, откровенно провалившись в тесте "Loop" и заняв последнее место в тесте "Big", что впрочем мало разочарует поклонником ASP, т.к. данная технология занимает несколько другую нишу, а большая производительность в некоторых тестах может объясняется скорее не преимуществами СТ сколько особенностями операционной системы (в смысле меньшими системными издержками NT в сравнении c RedHat). С другой стороны пользователю нет дела до этого, поэтому можно сказать, что, несмотря на посредственные показатели ASP выглядит вполне достойно. Впрочем вопрос выбора между ASP и Perl/PHP по критерию скорости вообще практически никогда не ставится — СТ выбирается в зависимости от операционной системы и предпочтений программистов/администраторов (хотя возможен и обратный вариант — выбор ос в зависимости от планируемой СТ, но это уже совсем другой разговор).

Часть III

Определившись с быстродействием систем в общем, акцентируем внимание на Perl и PHP, как на самых популярных в России платформах.

WinNT 4.0 SP6, CPU: PII-300, HTTP 1.0, Socrates local.

Первое место вполне резонно занимает IIS 4.0 при обработке статичной страницы, т.е. «голый» веб-сервер. Но как говорили в старину — «удивительно рядом» — на втором месте, с небольшим отставанием находится полноценная СТ. Правда у этого результата есть объяснение — встроенный веб-сервер, который по определению, менее функционален и как следствие быстрее. И только на третьем месте полноценный набор IIS 4.0 + ASP VBScript. Опять же удивительно ведет себя SSI — лишь четвертое место. Обладая гораздо меньшей функциональностью, по логике SSI должен был занять второе место, сразу после «голого» сервера, ан нет, видно оптимизация подкачала.

Впервые СТ с веб-сервером Apache встречаются лишь начиная с пятого места, что впрочем вполне логично, учитывая что Windows не является его родной ОС. Хит парад для данного сервера, тоже не вполне логичен — сначала голая платформа, затем JAVA, SSI, ASP, Mod_Perl, т.е. JAVA опять опережает SSI, а Perl откатывается к пятой строчке среди Apache (и девятой строчке, в общем зачете).

Теперь перейдем на другую ОС, чтобы понять, как ведут себя perl и php в более привычной, для них, среде.

Linux 2.2.7 CPU: PII-233, HTTP 1.0, ApacheBench, local, Session — NO.

Как и следовало ожидать, даже при меньшей тактовой частоте процессора, Apache и Perl под Linux, показали лучшие результаты, нежели при тестировании на PII-300 под WinNT, т.е. при более дорогостоящей аппаратной части, Windows, которая сама по себе не бесплатна, не обеспечивает сравнимого уровня производительности [2], для всех не "ASP" платформ. Что касается «разборок» внутри Linuх, то PHP побеждает с небольшим отрывом. Впрочем, если вы обратите внимание на результаты в первой части, то при тестировании, близким по своей сути, тестом "Hello", Perl наоборот значительно опережает PHP, правда, под другой ОС — RedHat [3]. Другими словами, даже в пределах *nix систем возможны значительные флуктуации результатов. Похоже, более менее постоянным, является лишь лидирование JSP, тогда как PHP и Perl меняются местами, от теста к тесту, от одной ОС к другой.

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

[1] — Так, отправной точкой для данной статьи явились результаты приведенные на www.caucho.com, si.infonet.ee, www.pendragon-software.com, а также материалы "Web Application Benchmarks :: Hello World".
[обратно к тексту]

[2] — Впрочем, может быть верно и обратное — портированние версий Apache, PHP, Perl и других программ под Windows выполнено хуже, по крайней мере в смысле производительности, что впрочем для потребителя не важно.
[обратно к тексту]

[3] — Данная разница также может объясняться влиянием отличий в методиках тестирования, даже, несмотря на их видимую простоту.
[обратно к тексту]