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.
Продолжение читайте тут.
а если выкинуть ZendOpt и поставить eaccelerator (http://eaccelerator.net/ ) ???
2maserg:
Думаю разница будет не очень существенна.
Проверить не могу, т.к. машина в продакшне и трогать её не рекомендуется.
Со веременем повторю тест на более мощной машине с 5м PHP + EAccelerator.
разница может быть существенна. ставил Xcache – получил прирость в 1.5 раза и уменьшение используемой php памяти в 4 раза (по данным php_get_memory_peak_usage). При этом Zend Optimizer не дает практически ничего.
Стоит ещё учитывать что при использовании разных bytecode-кешеров – повышение/понижение производительности прямо зависит от того, что этот код делает.
В первую очередь это связано с разными алгоритмами кеширования, применяемых в акселераторах.
Да, это верно. просто почему прорекламировал – потому что на моих *типовых* вебсайто-проектах xcache вел себя стереотипно хорошо. Также проверял и на не-моих проектах – с тем же результатом… Разумеется, за “любой” код не поручусь. Плюс имеет некий кэш переменных, куда можно помещать данные на время…
Мне кажется что использование кеша переменных (memcached), в контексте данного тестирования, будет большим булыжником в сторону PHP т.к. ни один внешний кеш переменных по скорости доступа не сравнится с доступом к Java переменной внутри одной Java-машины :)
(имеется ввиду случай когда кеш переменных реализован, например, статическим членом класса сервлета)
Ну да, но ведь мы же сравниваем две платформы в плане производительности. Кэш переменных в ряде случаев даст прирост производительности php. Кеш данных в сервлете возможен, но организуется несколько иначе, чем в php. Я же ни коим образом не защищаю ни ту ни другую технологию… Сам выбираю для своих проектов новую платформу, взвешиваю плюсы и минусы каждой. Склоняюсь таки к java (привычно, много стабильных готовых библиотек, быстро). В рамках java – выбираю из Groovy, JRuby, Helma (пока склоняюсь к Groovy, но Helma тоже неплохо)
Вот еще, что заметил. При своем тестировании понял, что java резко сбрасывает производительность при увеличении объема страниц. Php естественно, тоже, но почему-то в меньшей степени. Сам думаю, что это связано с алгоритмом конкатенации строк (использовал для создания объема).
Эта Helma http://dev.helma.org/ ?
Насколько я понял из беглого прочтения описания, смысл в её использовании отпадает с появлением Java 6.0 Scripting.
Или я не прав?
Эта. Не совсем. helma – полноценный web-framework. В качестве скриптового движка – Rhino. Сразу готова идеология приложений, контроллеров и плагинов. Отрадно – без проблем с UTF-8! В общем… на ее основу поставить бы Groovy, было бы, может быть, интересно…
сам подход к разработке понравился – распаковал -запустил батничек – работает. Закрыл консоль – не работает. Никаких томкэтов и деплоев на стадии разработки. Никаких консольных команд типа grails run-app. Вот эта какая-то человечность понравилась.
Спасибо за краткий экскурс – как появится чуть времени – гляну.
> выбираю из Groovy, JRuby, Helma
Странно, я б сперва на Jython смотрел.
2mix
странно, но все люди разные