Проблема производительности в рамках представления в Grails

Question

Я запускаю некоторый тест для отслеживания времени отклика приложения Grails.

Я использую структуру представления Grails для макета следующим образом:

В контроллере я определяю, какое представлениеи макет для использования

Затем я рендерим genericView с кодом, подобным следующему:

Так что этот genericView делает всю магию.

Я создаюФильтр производительности, который отслеживает, сколько времени занимает между afterController и beforeController (время контроллера) и между beforeController и renderView (время просмотра).

В макете у меня много тегов <g:pageProperty name="">, а в представлении -тот же номер в <content tag="..">, который вложен, включает в себя <g:include controller="..."/>.

. Это прекрасно работает, и это дает мне возможность повторно использовать макеты (как расположения частей html) и представления (отображения между расположениями и реальным содержимым).

Когда я беру среднее во времени просмотра, мне нужно 35 миллисекунд, чтобы сделать все включения.

Я думаю, что это много.

Знаете ли выЕсть ли какие-либо другие полезные альтернативы структуре Grails для включения и ансамбля представления при его визуализации?

Или, может быть, мне нужно использовать структуру лучше?

РЕДАКТИРОВАТЬ: Я только отмечаю, что время тратится на <g:include controller="..."/>.

Я включаю 4 контроллера в представление.Контроллер и включенные действия имеют только render "something". И время выглядит так:

Основной контроллер: Время контроллера: 3.98 Время просмотра: 43.87

Другие контроллеры (включены в основной вид): всего: 15,55

Таким образом, представление 4-х включений занимает 28,32 миллисекунд для запуска !

Любой указатель поможет.

Заранее спасибо.

Answer 1

С моим ограниченным развитием Grails ваша производительность кажется стандартной и ничего необычного.Я считаю, что это случай преждевременной оптимизации.Какие жесткие цели производительности вы ставите перед собой, пишете ли вы приложение, которое требует, чтобы время отклика находилось в пределах определенного значения?Вы сравнивали какие-либо другие модели контроллеров представления модели и инструменты разработки, такие как Spring Roo , чтобы увидеть, как сравнивается производительность и где они проводят время?Без дополнительной информации о вашем приложении трудно сказать, где будут ваши узкие места, но я предполагаю, что любые проблемы с производительностью, с которыми вы столкнетесь, будут более вероятны с вашими службами REST или доступом к базе данных.Это, вероятно, те области, на которых вы хотели бы сосредоточиться в первую очередь.Использование денежных средств Hibernate или обналичивание результатов ваших звонков REST, где это возможно, вероятно, поможет.

Answer 2

Groovy и Grails определенно имеют некоторые проблемы с производительностью, но в целом они незначительны, поскольку задержка базы данных и сети обычно составляет большую часть времени запроса. Поэтому мне было любопытно, когда я увидел этот вопрос и ожидал страшных цифр. 35 миллисекунд это очень быстро. Я думаю, у вас есть куда более важные вещи, о которых стоит беспокоиться.