Действительно ли производительность Grails 2.0 так ужасно низка?
Я несколько новичок в разработке веб-приложений на основе стека JVM, но для будущего проекта потребуется определенно какой-то веб-механизм на основе JVM. Поэтому я начал искать что-то для быстрого решения проблемы и повернулся, чтобы попробовать Grails. Все выглядело хорошо из книги, но, будучи впечатленным очень долгим временем запуска (grails run-app), я решил проверить, как это работает под нагрузкой. Вот:
Тестовое приложение: следуйте нескольким инструкциям, чтобы сделать его с нуля (занимает 2 минуты, если у вас уже установлены Grails и Tomcat):
_http: //grails.org/Quick+Start
тестовый пример (с тестом Apache - поставляется с Apache httpd - _http: //httpd.apache.org):
ab.exe -n 500 -c _http: // localhost: 8080 / my-project / book / create
(Примечание: это просто отображает 2 поля ввода в стилизованном контейнере)
аппаратное обеспечение: Intel i5 650 (4Core * 3,2 ГГц), 8 ГБ Ram & Win Server 2003 x64
Результат ..
Грааль: 32 Req / Sec
Total transferred: 1380500 bytes
HTML transferred: 1297500 bytes
Requests per second: 32.45 [#/sec] (mean)
Time per request: 308.129 [ms] (mean)
Time per request: 30.813 [ms] (mean, across all concurrent requests)
Transfer rate: 87.51 [Kbytes/sec] received
(Только 32 Req / Sec со 100% насыщением процессора, это намного ниже моих ожиданий для такого оборудования)
... Далее - я попытался сравнить его, например, с аналогичным фиктивным JSF-приложением (я взял его здесь: _http: //www.ibm.com/developerworks/library/j-jsf2/ - ищите «Исходный код с файлами JAR» "есть \ jsf-example2 \ target \ jsf-example2-1.0.war внутри),
контрольный пример: ab.exe -n 500 -c 10 _http: // localhost: 8080 / jsf / backend / list.jspРезультат ..
JSF: 400 Req / Sec
Total transferred: 5178234 bytes
HTML transferred: 5065734 bytes
Requests per second: 405.06 [#/sec] (mean)
Time per request: 24.688 [ms] (mean)
Time per request: 2.469 [ms] (mean, across all concurrent requests)
Transfer rate: 4096.65 [Kbytes/sec] received
... и, наконец, идет необработанный манекен JSP (просто для справки)
Jsp: 8000 рэк / сек:
<html>
<body>
<% for( int i = 0; i < 100; i ++ ) { %>
Dummy Jsp <%= i %> </br>
<% } %>
</body>
</html>
Результат:
Total transferred: 12365000 bytes
HTML transferred: 11120000 bytes
Requests per second: 7999.90 [#/sec] (mean)
Time per request: 1.250 [ms] (mean)
Time per request: 0.125 [ms] (mean, across all concurrent requests)
Transfer rate: 19320.07 [Kbytes/sec] received
...
Я что-то пропустил? ... а приложение Grails может работать намного лучше?
PS: я попытался профилировать свое приложение Grails с VisualVM, но получил бесконечный цикл сообщений вроде ...
Profiler Agent: Redefining 100 classes at idx 0, out of total 413
...
Profiler Agent: Redefining 100 classes at idx 0, out of total 769
...
И, наконец, приложение просто перестало работать через несколько минут - так что, похоже, профилирование Grails - не лучший выбор для хорошей диагностики.
Обновить - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Прежде всего, мне нужно администратор, да, мне нужен RTFM, т. Е. «Grails run-app» не является правильным способом запуска Grails для измерения производительности. После компиляции WAR и его развертывания на Tomcat производительность не так уж и низка - она просто низкая. Приведенные ниже показатели предназначены для параллелизма 1 пользователя (я просто хотел проверить, какова максимальная производительность фреймворка в одном потоке и без большой нагрузки), и, читая другие связанные посты, я пришел на страницу http://stackoverflow.com/ questions / 819684 / jsf-and-spring-performance-vs-bad-jsp-performance "и решил проверить Apache Wicket, упомянутый там - его производительность также включена.
Вариант использования: - ab.exe -n 500 -c 1 _http: // localhost: 8080 / ... - сервером является Tomcat7 в выпуске vFabric tcServer Dev с «insight», работающим в фоновом режиме
---------------------- tcServer Plain Tomcat 7 -c 10
/Grails/book/create 77 req/sec 130 req/sec 410 req/sec
/jsf/backend/listing.jsp 133 req/sec 194 req/sec 395 req/sec
/wicket/library/ 870 req/sec 1400 req/sec 5300 req/sec
Так что ... в любом случае с Граилсом что-то не так. Я сделал некоторое профилирование с использованием tcServer (спасибо Karthick) - похоже, он может только отслеживать «Spring-ориентированные» действия, а внутренняя трассировка стека для Grails выглядит следующим образом (для 2 запросов - примечание: показатели нестабильны - я уверен, что точность) tcServer далеко не идеален, но может быть использован только для информации)
Total (81ms)
Filter: urlMapping (32ms)
-> SimpleGrailsController#handleRequest (26ms)
-> Render view "/book/create" (4ms)
Render view "/layouts/main.gsp" (47ms)
Total (79ms)
Filter: urlMapping (56ms) ->
-> SimpleGrailsController#handleRequest (4ms)
-> Render view "/book/create" (38ms)
Render view "/layouts/main.gsp" (22ms)
PS: может случиться так, что причина плохой производительности в Grails лежит в основе библиотек Spring, проверим это более подробно.