1. Индивидуальные запросы, как таковые, в Hibernate нормальные, можете включить дебаг и проверить. Проблема в том как Hibernate ими пользуется, и его весь остальной функционал. Hibernate (и JPA в целом) ужасная реализация ORM.
2. Вместо них, советую посмотреть Ebean ORM, выглядит намного лучше.
3. В любом случае, почти любой ORM нормально справится с подтяжкой ManyToOne графа, и это удобно. Все что сложнее, есть наивные запросы, что не значит, что не нужно использовать ORM для простых случаев. Вот только JPA не очень здесь способствует, и в частности не любит дружить с графами объектов, которые были сформированы извне, руками разработчика (что обычно происходит в случае ручного маппинга результатов нативного сложного запроса). Ebean опять же здесь смотрится лучше.
4. По поводу реактивных драйверов. Известная статья HikariCP по поводу размеров connection пула к базе даёт понять, что не так уж и много одновременных запросов мы можем себе позволить, а значит и подключений (потоков) тоже. Тогда в целом реактивность, которая в теории даёт кучу подключений за дёшево, особо и не вперлась. А если же все таки ваша база способна выдержать сотни запросов, то это уже стоит вам столько, что наверняка можно себе позволить пару сотен потоков на бекенд приложении. В том числе, бекенды обычно в кластере, и возможности базы распределяются между ними всеми, так что пул каждого пропорциально нужно будет уменьшить.
5. R2DBC фу, ни ORM ни то ни сё. Слишком мало может.
Не делайте таких выводов по Web Framework Benchmarks. Там сетап всех приложений абсолютно разный, поддерживается самими комьюнити. Хотя все и участвуют в одном рейтинге, за идентичностью никто не следит.
Бенчмарки дело такое, нужно очень чётко посмотреть исходник, понять что именно измеряется и о чем говорят результаты, а потом признать, что все таки не понял, и ещё раз смотреть, и так раз 10.
По тенической части, это наверное полезно, если стало работать быстрее, пользователям конечно лучше.
Но выводы по метрикам в конце - мизерные проценты на уровне погрешности, и врядли учитывают естественный прирост пользователей со временем (без ваших улучшений), сезонность, настроение населения итп миллион причин. Я бы не стал делать выводы по таким результатам.
Не прям уж маркетинговый. Тут юзер понимает как можно сообщить ресторану если что-то не понравилось - оставить негативный отзыв (который бургер кингу может и не нужен), почувствовать важность, повлиять на ресторан, или наборот, похвалить, помочь оценить ресторан для других юзеров (а значит и себя самого).
Продвижение Project Loom, это здорово. Будут интересны результаты Spring MVC, когда появится "коробочная" версия, без танцев с бубном.
В тестах Spring MVC, надеюсь, количество tomcat потоков было увеличено с дефолтных 100?
Советую сделать тесты с jetty - изменение одной строки, по прежнему коробочный MVC, а производительность намного выше (по моим наблюдениям).
Хочется отметить ещё раз важность понимания что именно тестируется. Тесты WebMvc Jdbi это наглядно демонстрируют. Может получиться так, что не так далеко нужно уйти от коробочной версии, чтобы получит схожий буст производительности. Ещё пример - Spring Data и нативный R2DBC имеют разницу в примерно 1.5 раза.
Все таки важно тестировать на разных машинах. В частности, сетевые запросы к бд, вроде бы, и не идут через local loopback, из-за использования докера, но подозреваю, что все таки, это намного быстрее реального сетевого запроса. В реальности вся видимая разница может исчезнуть.
Важно тестировать на нескольких CPU. Например, R2DBC прям до недавнего времени имел огромную деградацию, проявляющуюся на многоядерности.
Про деньги - как бы да, дешевле. Но нужно помнить и про затраты на танцы с новым фреймворком. Его дружбе со всей другой экосистемой итп. Посчитайте сколько стоит один разраб в год, занимающийся этим.
Как по мне, WebServer.builder() такая же "магия" как и @RestController. Как ни крути, любой фреймворк, его поведения итд нужно учить и понимать. Не избежать этого, хоть с аннотациями, что без.
Согласен, Java быстрая. Нужны просто прямые руки. А если прям 200% уверены, что ботлнек не в бд, то есть Vertx с Vertx Sql Client.
Помните, переписав свой проект с нуля, зачастую получится быстрее даже на старом фреймворке! :)
А вам не кажется дикостью оценивать человека по количеству написанных им юнит тестов? Разные тесты требуют разное время на понимание тестируемого компонента, решение трудностей при написании теста из-за того как этот компонент написан.
Может быть вы еще и по объему кода человека оцениваете?
Как вы заботитесь о своей производительности (прибыльности) понятно. Расскажите как вы заботитесь о росте своих сотрудников, включая soft и hard skills.
Сори за некропостинг, но можно узнать что за 90 дней? Дедик в селектеле на заказ за 5 дней соберут.
1. Индивидуальные запросы, как таковые, в Hibernate нормальные, можете включить дебаг и проверить. Проблема в том как Hibernate ими пользуется, и его весь остальной функционал. Hibernate (и JPA в целом) ужасная реализация ORM.
2. Вместо них, советую посмотреть Ebean ORM, выглядит намного лучше.
3. В любом случае, почти любой ORM нормально справится с подтяжкой ManyToOne графа, и это удобно. Все что сложнее, есть наивные запросы, что не значит, что не нужно использовать ORM для простых случаев. Вот только JPA не очень здесь способствует, и в частности не любит дружить с графами объектов, которые были сформированы извне, руками разработчика (что обычно происходит в случае ручного маппинга результатов нативного сложного запроса). Ebean опять же здесь смотрится лучше.
4. По поводу реактивных драйверов. Известная статья HikariCP по поводу размеров connection пула к базе даёт понять, что не так уж и много одновременных запросов мы можем себе позволить, а значит и подключений (потоков) тоже. Тогда в целом реактивность, которая в теории даёт кучу подключений за дёшево, особо и не вперлась. А если же все таки ваша база способна выдержать сотни запросов, то это уже стоит вам столько, что наверняка можно себе позволить пару сотен потоков на бекенд приложении. В том числе, бекенды обычно в кластере, и возможности базы распределяются между ними всеми, так что пул каждого пропорциально нужно будет уменьшить.
5. R2DBC фу, ни ORM ни то ни сё. Слишком мало может.
6. Ждём продакшен Loom.
Не делайте таких выводов по Web Framework Benchmarks. Там сетап всех приложений абсолютно разный, поддерживается самими комьюнити. Хотя все и участвуют в одном рейтинге, за идентичностью никто не следит.
Бенчмарки дело такое, нужно очень чётко посмотреть исходник, понять что именно измеряется и о чем говорят результаты, а потом признать, что все таки не понял, и ещё раз смотреть, и так раз 10.
По тенической части, это наверное полезно, если стало работать быстрее, пользователям конечно лучше.
Но выводы по метрикам в конце - мизерные проценты на уровне погрешности, и врядли учитывают естественный прирост пользователей со временем (без ваших улучшений), сезонность, настроение населения итп миллион причин. Я бы не стал делать выводы по таким результатам.
Не прям уж маркетинговый. Тут юзер понимает как можно сообщить ресторану если что-то не понравилось - оставить негативный отзыв (который бургер кингу может и не нужен), почувствовать важность, повлиять на ресторан, или наборот, похвалить, помочь оценить ресторан для других юзеров (а значит и себя самого).
Продвижение Project Loom, это здорово. Будут интересны результаты Spring MVC, когда появится "коробочная" версия, без танцев с бубном.
В тестах Spring MVC, надеюсь, количество tomcat потоков было увеличено с дефолтных 100?
Советую сделать тесты с jetty - изменение одной строки, по прежнему коробочный MVC, а производительность намного выше (по моим наблюдениям).
Хочется отметить ещё раз важность понимания что именно тестируется. Тесты WebMvc Jdbi это наглядно демонстрируют. Может получиться так, что не так далеко нужно уйти от коробочной версии, чтобы получит схожий буст производительности. Ещё пример - Spring Data и нативный R2DBC имеют разницу в примерно 1.5 раза.
Все таки важно тестировать на разных машинах. В частности, сетевые запросы к бд, вроде бы, и не идут через local loopback, из-за использования докера, но подозреваю, что все таки, это намного быстрее реального сетевого запроса. В реальности вся видимая разница может исчезнуть.
Важно тестировать на нескольких CPU. Например, R2DBC прям до недавнего времени имел огромную деградацию, проявляющуюся на многоядерности.
Про деньги - как бы да, дешевле. Но нужно помнить и про затраты на танцы с новым фреймворком. Его дружбе со всей другой экосистемой итп. Посчитайте сколько стоит один разраб в год, занимающийся этим.
Как по мне,
WebServer.builder()такая же "магия" как и@RestController. Как ни крути, любой фреймворк, его поведения итд нужно учить и понимать. Не избежать этого, хоть с аннотациями, что без.Согласен, Java быстрая. Нужны просто прямые руки. А если прям 200% уверены, что ботлнек не в бд, то есть Vertx с Vertx Sql Client.
Помните, переписав свой проект с нуля, зачастую получится быстрее даже на старом фреймворке! :)
Есть же Pingdom.
Может быть вы еще и по объему кода человека оцениваете?
Как вы заботитесь о своей производительности (прибыльности) понятно. Расскажите как вы заботитесь о росте своих сотрудников, включая soft и hard skills.