Архивы: по дате | по разделам | по авторам

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

АрхивСетевое окружение (архив)
автор : Андрей Драница   09.10.2002

...или 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.

Технология
File
Servlet
Hello
Big
DB
Cache
Resin/IBM
694
628
575
108
161
645
Resin/JDK1.2
509
451
480
74
85
474
Resin/Apache/IBM
550
390
417
55
104
438
Orion/JDK1.2
488
186
360
69
88
72
Mod_php/Apache
561
 
291
52
117
117
Mod_perl/Apache
550
 
365
92
111
111
ServletExec/Apache/IBM
536
98
103
 
59
59
Tomcat/IBM
129
100
94
20
50
50
CGI perl/Apache
550
 
67
28
7
7
JRun/Apache/JDK1.2
531
69
37
 
25
25
Tomcat/JDK1.2
37
62
37
12
24
24

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

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

Практически во всех тестах безусловным лидером является 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 запроса в секунду. Даже учитывая, что запрос обрабатывается (не передается, а именно выполняется) сервером за секунду (что на самом деле есть преувеличение) получатся, что четыре запроса одновременно это очень хорошая загрузка).

Технология
File
Servlet
Hello
Loop
Big
DB
Cache
Resin/IBM
571
550
558
36
83
131/268
603
Resin/Apache/IBM
505
373
386
36
65
122/202
382
Resin/IIS
730
348
364
32
46
--
--
mod_perl/Apache
497
n/a
322
11
74
98
--
ASP/IIS
727
n/a
317
1.5
31
--
--
mod_php/Apache
504
n/a
308
13
36
130
--
Resin JS/Apache/IBM
484
n/a
254
16
61
33/118
376

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

Технология
File
Servlet
Hello
Loop
Big
DB
Cache
Resin/IBM
1455
1187
1553
46
96
176/367
1561
Resin/Apache/IBM
880
564
575
38
91
135/237
586
Resin/IIS
1619
417
422
35
48
--
--
mod_perl/Apache
801
n/a
385
11
97
93
--
ASP/IIS
1654
n/a
385
1.4
80
--
--
mod_php/Apache
869
n/a
342
13
44
141
--

Тест «Четыре пользователя». Показатели в таблице представляют суммарную производительность, т.е. общее количество операций выполненных для всех четырех клиентов сервером. Программа клиент в запросе указывала запрос на включение режима 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, как на самых популярных в России платформах.

Место
HITS/S
CODE TYPE
WEB SERVER
APPLICATION
SESSION
1
299
HTML
iis 4.0
static_html
no
2
295
JSP Java
resin httpd
resin 1.1b5
no
3
194
ASP VBScript
iis 4.0
asp/vbscript
yes
4
159
SSI Include
iis 4.0
ssi_inc
no
5
90
HTML
apache 1.3.6
static_html
no
6
82
JSP Java
apache 1.3.6
resin 1.1b5
no
7
71
SSI Include
apache 1.3.6
mod_include
no
8
65
ASP VBScript
apache 1.3.6
openasp
yes
9
60
ModPerl Handler
apache 1.3.6
mod_perl
no
10
52
Perl CGI
apache 1.3.6
mod_perl/registry
no
11
48
Embperl
apache 1.3.6
mod_perl/embperl 1.2b10
no
12
43
ASP PerlScript
apache 1.3.6
mod_perl/asp .19
no
13
41
RXML
roxen 1.3.2
roxen/challenger
no
14
40
Embperl
apache 1.3.6
mod_perl/embperl 1.3b2
no
15
40
SSI Include
apache 1.3.6
mod_perl/ssi_inc
no
16
40
SSI Include
apache 1.3.6
mod_perl/asp.18/ssi_inc
no
17
39
XML, XSLT, etc.
apache 1.3.6
mod_perl/asp .19 subs
no
18
35
XML, XSLT, etc.
apache 1.3.6
mod_perl/asp .19 xslt
no
19
24
ASP PerlScript
apache 1.3.6
mod_perl/asp .19
SDBM_File
20
22
ASP PerlScript
iis 4.0
asp/perlscript 522
yes
21
22
ASP PerlScript
apache 1.3.6
mod_perl/asp .18
DB_File
22
22
ASP PerlScript
iis 4.0
asp/perlscript 522
no

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 в более привычной, для них, среде.

Место
HITS/S
CODE TYPE
WEB SERVER
APPLICATION
1
297
HTML
apache 1.3.6
static_html
2
173
PHP
apache 1.3.6
mod_php 3.0.11
3
169
ModPerl Handler
apache 1.3.6
mod_perl 1.21
4
125
Jolt
enhydra
jolt
5
71
Embperl
apache 1.3.6
mod_perl/embperl 1.2b5
6
70
Java Servlet
apache 1.3.6
jrun 2.3
7
70
Java Servlet
jrun_httpd 2.3
jrun 2.3
8
50
Java Servlet
apache 1.3.6
mod_jserv 1.0

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] — Данная разница также может объясняться влиянием отличий в методиках тестирования, даже, несмотря на их видимую простоту.
[обратно к тексту]

© ООО "Компьютерра-Онлайн", 1997-2021
При цитировании и использовании любых материалов ссылка на "Компьютерру" обязательна.