Я несколько новичок в разработке веб-приложений на основе стека 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 (4 ядра * 3,2 ГГц), 8 ГБ Ram & Win Server 2003 x64
Результат - ..
Grails: 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 inside),
- контрольный пример: ab.exe -n 500 -c 10 _ http://localhost:8080/jsf/backend/listing.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 пользователя (я просто хотел проверить, какова максимальная производительность фреймворка в одном потоке без большой нагрузки), и, читая другие связанные посты, я пришел к «/831448/proizvoditelnost-jsf-i-spring-po-sravneniy-s-nizkoi-proizvoditelnosty-jsp" и решил проверить Apache Калитка упоминается там - ее производительность также включена.
Вариант использования:
- 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, проверим это более подробно.