Apache/PHP VS Tomcat/Groovy

Рубрика: Development, Groovy, Java | 20 October 2006, 16:37 | Vadim Voituk

Дернуло меня на днях опять в J2EE нос сунуть.
Поставил на одном из серверов JDK 1.6-beta, развернул Tomcat, “прикрутил” к нему Groovy, указал стандартные JSP-taglibs, и для теста написал простенький сервлет, какой выводит User-Agent посетителя. Позже ещё и аналогичную JSP страницу.

Все бы хорошо, но почему-то визуально казалось что работает это все медленно, чего ввиду HotSpot-компиляции Java быть не должно. Решил проверить с помошью утилиты “ab” скорость обработки запросов полученого “J2EE-монстра” и сравнить с данными полученными от связки Apache/PHP/ZendOptimizer.

Запускал так:

ab -n 1000 -c 100 http://somehost.com/GroovyTest
ab -n 1000 -c 100 http://somehost.com/test.php

и фиксировал значение Request Per Second
В результате поулчились такие числа (request/sec.):

Apache/mod_php4/ZendOptimizer:
PHP-скрипт = 363, 380, 325, 349, 351
Статичный HTML = 365, 315, 420, 288, 320

Tomcat 5.5.20/Groovy 1.0.6/JDK 1.6
GroovyServlet = 1375, 889, 1203, 1367
Статичный HTML = 2070, 2155, 1865, 2105

В результате получается что Tomcat+Groovy на простеньких приложениях за секунду обрабатывает почти в 4 раза больше запросов чем Apache/mod_php4/ZendOpt.
На отдаче статичного html-контента это число вырастает ещё на 20%.
На таком же приложении, но с использованием MySQL (примитивный SELECT в базу), Tomcat+Groovy проигрывают в производительности на 10%.
Скорее всего это связано с довольно низкой производительностью JDBC.

Продолжение читайте тут.

Комментариев: 12

12 Responses to “Apache/PHP VS Tomcat/Groovy”

Комментарии:

  1. maserg

    а если выкинуть ZendOpt и поставить eaccelerator (http://eaccelerator.net/ ) ???

  2. vadim

    2maserg:
    Думаю разница будет не очень существенна.
    Проверить не могу, т.к. машина в продакшне и трогать её не рекомендуется.
    Со веременем повторю тест на более мощной машине с 5м PHP + EAccelerator.

  3. schleicher

    разница может быть существенна. ставил Xcache – получил прирость в 1.5 раза и уменьшение используемой php памяти в 4 раза (по данным php_get_memory_peak_usage). При этом Zend Optimizer не дает практически ничего.

  4. vadim

    Стоит ещё учитывать что при использовании разных bytecode-кешеров – повышение/понижение производительности прямо зависит от того, что этот код делает.
    В первую очередь это связано с разными алгоритмами кеширования, применяемых в акселераторах.

  5. schleicher

    Да, это верно. просто почему прорекламировал – потому что на моих *типовых* вебсайто-проектах xcache вел себя стереотипно хорошо. Также проверял и на не-моих проектах – с тем же результатом… Разумеется, за “любой” код не поручусь. Плюс имеет некий кэш переменных, куда можно помещать данные на время…

  6. vadim

    Мне кажется что использование кеша переменных (memcached), в контексте данного тестирования, будет большим булыжником в сторону PHP т.к. ни один внешний кеш переменных по скорости доступа не сравнится с доступом к Java переменной внутри одной Java-машины :)
    (имеется ввиду случай когда кеш переменных реализован, например, статическим членом класса сервлета)

  7. schleicher

    Ну да, но ведь мы же сравниваем две платформы в плане производительности. Кэш переменных в ряде случаев даст прирост производительности php. Кеш данных в сервлете возможен, но организуется несколько иначе, чем в php. Я же ни коим образом не защищаю ни ту ни другую технологию… Сам выбираю для своих проектов новую платформу, взвешиваю плюсы и минусы каждой. Склоняюсь таки к java (привычно, много стабильных готовых библиотек, быстро). В рамках java – выбираю из Groovy, JRuby, Helma (пока склоняюсь к Groovy, но Helma тоже неплохо)

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

  8. vadim

    Эта Helma http://dev.helma.org/ ?
    Насколько я понял из беглого прочтения описания, смысл в её использовании отпадает с появлением Java 6.0 Scripting.
    Или я не прав?

  9. schleicher

    Эта. Не совсем. helma – полноценный web-framework. В качестве скриптового движка – Rhino. Сразу готова идеология приложений, контроллеров и плагинов. Отрадно – без проблем с UTF-8! В общем… на ее основу поставить бы Groovy, было бы, может быть, интересно…
    сам подход к разработке понравился – распаковал -запустил батничек – работает. Закрыл консоль – не работает. Никаких томкэтов и деплоев на стадии разработки. Никаких консольных команд типа grails run-app. Вот эта какая-то человечность понравилась.

  10. vadim

    Спасибо за краткий экскурс – как появится чуть времени – гляну.

  11. mix

    > выбираю из Groovy, JRuby, Helma

    Странно, я б сперва на Jython смотрел.

  12. merge

    2mix

    странно, но все люди разные

Leave a Reply