Комментарии 12
Очень интересный подход. Хотя, по моему, ему сложно найти применение. В реальной жизни вызываются сервисы, которые подвязаны на спринг. Было бы интересно сделать такой же тест, но, вместо просто возврата текста, вернуть текст сгенерированный спринговым бином с какой-то @Secured аннотацией. Я думаю, что в реальности проще отдельную виртуалку запустить параллельно.
Согласен, что подход имеет довольно узкую область применений. Однако он взят с реального проекта, где позволяет хорошо сэкономить на серверах.
в реальности проще отдельную виртуалку запустить параллельно
Полностью поддерживаю.
Из вот этих приседаний с рефлексией и undertow-обработчиками, я бы подумал просто о кастомной сортировке этих самых хендлеров, чтобы более нагруженные контроллеры встали в начало списка, чтобы быстрее находились при проходе по нему.
А ещё можно на ассемблере написать - просто летать будет. Естественно что спринг добавляет оверхед и если его не использовать будет быстрее, но удобнее - большой вопрос
видимо что-то в дефолтной конфигурации томката недооптимизировано
Это все верно для пустого контроллера. Как только появится работа с бд/диском/внешней системой с некотролируемыми задержками/любой другой IO, так сразу разница станет настолько несущественной, что ей можно будет пренебречь
Хотелось бы увидеть стек вызовов для вашего «оптимизированного» решения. Если там всё мимо Spring MVC пролетает, то это весьма сомнительное решение и назвать его Spring REST API уже нельзя (а заголовок у вас именно такой).
выкидываем спринг - получаем профит! )
Ускорение Spring REST API на 200%