Comments 4
Лучший способ увеличить быстродействие микросервисов — отказаться от SpringBoot
«Магия» SpringBot которая позволяет писать «быстро» и «меньше» кода, она не просто так…
Все эти обходы классов при старте и обработка аннотаций она дает приличную задержку.
Как то, просто из за спора, нарисовал альтернативу серверной части на jersey конкретного модуля (довольного простого… с 10к API функций и работа с БД через простые select и вызовы PL/SQL процедур).
Так вот без SpringBoot стартует до момента «готов принимать HTTP» на 500 ms дольше.
Объем кода — практически тот же.
Чет все помешались на этом SpringBoot…
«Магия» SpringBot которая позволяет писать «быстро» и «меньше» кода, она не просто так…
Все эти обходы классов при старте и обработка аннотаций она дает приличную задержку.
Как то, просто из за спора, нарисовал альтернативу серверной части на jersey конкретного модуля (довольного простого… с 10к API функций и работа с БД через простые select и вызовы PL/SQL процедур).
Так вот без SpringBoot стартует до момента «готов принимать HTTP» на 500 ms дольше.
Объем кода — практически тот же.
Чет все помешались на этом SpringBoot…
так тут фишка не в том что бы уменьшить время для «готов принимать HTTP», а время на обработку запросов. И статья, как сделать пару тривиальных действий и можно улучшить перфоманс.
Как по мне не очень критично сколько грузится сервис — 4 сек или 10. Зато профита больше(как минимум поддерживать проще проект будет)
Как по мне не очень критично сколько грузится сервис — 4 сек или 10. Зато профита больше(как минимум поддерживать проще проект будет)
Не скажите… время на поднятие инстанса иногда то же очень важно.
Но а то что в статье описано — это вообще прямого отношения к SpringBoot не имеет.
Размер пула соединений у HTTP клиента и игры с количеством нитей на входящие соединения и количетвом открытых сокетов у HTTP сервера (tomcat ли, jetty, grizzly) в режиме не NIO — это вообще азы.
Тем более такие несуразные игры.
Ага… щаз… Connection refused после 80
Нахрена, если сервис — «труба» и всего 80 входящих одновременно.
Автор либо не понимает зачем он крутит эти параметры либо просто тяп ляп статья.
Показывать, что повышаешь производительность сервера тем что усовершенствуешь функцию (сбора статистики производительности — это вообще лютый бред.
parallelStream со сбором результата обращений в динамике. Мда… Ну то же «решение» с подкручиванием через java.util.concurrent.ForkJoinPool.common.parallelism
Причем тут вообще SpringBoot я не понял, но возмутился именно тому, что все описанное вообще прямого отношения к framework (SpringBoot) не имеет.
Но а то что в статье описано — это вообще прямого отношения к SpringBoot не имеет.
Размер пула соединений у HTTP клиента и игры с количеством нитей на входящие соединения и количетвом открытых сокетов у HTTP сервера (tomcat ли, jetty, grizzly) в режиме не NIO — это вообще азы.
Тем более такие несуразные игры.
server.tomcat.max-connections=80
server.tomcat.max-threads=160
Приложение будет отклонять запросы на подключение и отвечать ошибкой «Connection refused» (отказ соединения) всем клиентам, как только количество подключений достигнет 160.
Ага… щаз… Connection refused после 80
Таким образом, приложение может поддерживать до 2000 HTTP-соединений в пуле в течение 10 секунд.
Нахрена, если сервис — «труба» и всего 80 входящих одновременно.
Автор либо не понимает зачем он крутит эти параметры либо просто тяп ляп статья.
Показывать, что повышаешь производительность сервера тем что усовершенствуешь функцию (сбора статистики производительности — это вообще лютый бред.
parallelStream со сбором результата обращений в динамике. Мда… Ну то же «решение» с подкручиванием через java.util.concurrent.ForkJoinPool.common.parallelism
Причем тут вообще SpringBoot я не понял, но возмутился именно тому, что все описанное вообще прямого отношения к framework (SpringBoot) не имеет.
Да, Вы все правильно говорите — нужно комплексно подходить и подкручивать только там где необходимо и понимать зачем крутишь.
Важности не отрицаю, но разница в 10 секунд не критичная. Приложение редко перезапускаем, а если и перезапускаем всегда есть еще как минимум одно плечо, которое возьмет на себя нагрузку.
За автора отвечать не буду, но выглядит так, что автор хотел показать что вообще можно сделать и Spring тут как каркас, который сейчас очень(ну прям очень) много где используется. Да это и не плохо.
Думаю, статья имеет право на жизнь. Да она будет не очень полезна продвинутым разработчикам, но ребятам у кого не было опыта — покажет какие инструменты есть и надеюсь они пойдут читать как это все работает, что бы осознанно тюнить свое приложение
Не скажите… время на поднятие инстанса иногда то же очень важно.
Важности не отрицаю, но разница в 10 секунд не критичная. Приложение редко перезапускаем, а если и перезапускаем всегда есть еще как минимум одно плечо, которое возьмет на себя нагрузку.
Но а то что в статье описано — это вообще прямого отношения к SpringBoot не имеет
За автора отвечать не буду, но выглядит так, что автор хотел показать что вообще можно сделать и Spring тут как каркас, который сейчас очень(ну прям очень) много где используется. Да это и не плохо.
Думаю, статья имеет право на жизнь. Да она будет не очень полезна продвинутым разработчикам, но ребятам у кого не было опыта — покажет какие инструменты есть и надеюсь они пойдут читать как это все работает, что бы осознанно тюнить свое приложение
Sign up to leave a comment.
Улучшаем производительность Java-микросервиса парой простых приемов