Является ли производительность Grails 2.0 действительно ужасно низкой?

Я немного новичок в разработке WEB, основанный на стеке JVM, но для будущего проекта потребуется определенно некоторый движок WEB на основе JVM. Поэтому я начал изучать почву, чтобы быстро все исправить, и повернулся, чтобы попробовать Grails. Вещи хорошо смотрелись из книги, но, несмотря на очень длительное время запуска (grails run-app), я решил проверить, как это работает под нагрузкой. Вот он:

  • test 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

Результат:..

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 внутри),

  • тестовый пример: 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 req/sec:

<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 это не так уж и плохо - он просто низкий. Метрики ниже для concurrency 1 пользователя (я просто хотел проверить, что такое MAX-производительность фреймворка в одном потоке и без большой нагрузки), и при чтении других связанных сообщений здесь я пришел к "http://stackoverflow. com/info/819684/jsf-and- spring -performance-vs-poor-jsp-performance" и решил проверить упомянутый там Apache Wicket - его производительность также включена.

Вариант использования: - ab.exe -n 500 -c 1 _http://localhost: 8080/... - сервер Tomcat7 в vFabric tcServer Dev edition с "проницательностью", работающей на фоне

----------------------   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, а внутренняя stacktrace для 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 'libs, проверит это более подробно.

Ответы

Ответ 1

Запускаете ли вы его с помощью run-app?

http://grails.org/Deployment:

"Grails никогда не следует развертывать с помощью команды grails run-app, поскольку это устанавливает Grails в режиме" разработки ", который имеет дополнительные накладные расходы".

Ответ 2

попробуйте применить пример приложения к tomcat. grails run-app предназначен только для разработки.

Ответ 3

в какой среде вы запустили приложение? подталкивать? DEV?

Вы используете строительные леса?

Я пробовал это на своей машине (ядро i7-2600k). страницу входа с 4 полями ввода, динамическими макетами и некоторыми другими вещами. У меня 525 запросов в секунду в более медленной среде.

Ответ 4

Да, это контрольный пример того, кто не знает много о граале или его окружении; сначала он работает в Windows, понимая, что плохо работает в управлении ресурсами, поэтому большинство веб-сервисов/приложений обслуживаются в средах Linux.

Во-вторых, если он использует "ab" для сравнения, то у него нет настройки прокси-кеша, потому что после первого удара оставшаяся часть хитов будет кэшироваться, и теперь он сравнивает свой кеш с моим пониманием его установки.

Итак, все это похоже на бенчмаркинг плохой настройки и плохое понимание Grails. Никакое преступление не предназначено.