AM
сказки, спринг еще как быстр может быть
а разве нельзя в спринге поотключать всё что не нужно ? (я зеленый, может бред несу)
Size: a a a
2020 December 12
AE
НО, если взять тот же вебфлакс - там роутинг до контроллера 2-3 мс, так что норм
AE
а разве нельзя в спринге поотключать всё что не нужно ? (я зеленый, может бред несу)
сообщение выше
RS
не, mvc немного толст и на хэндлинг запроса тратит примерно 20-50 ms вне контроллера
потом приходят ребята, у которых сервис отвечает за 10 мс в сумме и такие - спринг гавно.
ну ок, ребята для вашего тайминга такое оверхэд, а когда бизнес логика вместе с походом в бд или еще кудато вываливается в сотни миллисек, то на эти 20-50 уже похер
потом приходят ребята, у которых сервис отвечает за 10 мс в сумме и такие - спринг гавно.
ну ок, ребята для вашего тайминга такое оверхэд, а когда бизнес логика вместе с походом в бд или еще кудато вываливается в сотни миллисек, то на эти 20-50 уже похер
ну не знаю, если убрать сеть из уравнения, запустив сервис на локалхосте, то запрос, возвращающий немного данных из кэша через МВЦ-контроллер, отрабатывает за 6-8мс.
так что накладных расходов там явно не наберется на 50 мс. может, если кучу фильтров навесить.. (секьюрити уже есть)
по сути данный запрос почти ничего не делает, кроме доставания данных из кэша. так что наверное можно сказать, что 6-8 мс - это и есть накладные расходы самого спринга (диспетчер, фильтры, сериализация и прочее).
так что накладных расходов там явно не наберется на 50 мс. может, если кучу фильтров навесить.. (секьюрити уже есть)
по сути данный запрос почти ничего не делает, кроме доставания данных из кэша. так что наверное можно сказать, что 6-8 мс - это и есть накладные расходы самого спринга (диспетчер, фильтры, сериализация и прочее).
Э
Включаешь несколько стартеров => в контексте крутятся дохрена бинов. Они все реально нужны?
AE
Ruslan Stelmachenko
ну не знаю, если убрать сеть из уравнения, запустив сервис на локалхосте, то запрос, возвращающий немного данных из кэша через МВЦ-контроллер, отрабатывает за 6-8мс.
так что накладных расходов там явно не наберется на 50 мс. может, если кучу фильтров навесить.. (секьюрити уже есть)
по сути данный запрос почти ничего не делает, кроме доставания данных из кэша. так что наверное можно сказать, что 6-8 мс - это и есть накладные расходы самого спринга (диспетчер, фильтры, сериализация и прочее).
так что накладных расходов там явно не наберется на 50 мс. может, если кучу фильтров навесить.. (секьюрити уже есть)
по сути данный запрос почти ничего не делает, кроме доставания данных из кэша. так что наверное можно сказать, что 6-8 мс - это и есть накладные расходы самого спринга (диспетчер, фильтры, сериализация и прочее).
У меня замеры на пустом буте были больше, просто константу отдать из контроллера
AE
Но в целом да, медленность спринга - миф
RS
Ну я вот только что проверил постманом. Может постман криво считает, конечно. Такие тесты не то, чтобы сильно научно правдивы. :)
RS
Включаешь несколько стартеров => в контексте крутятся дохрена бинов. Они все реально нужны?
на производительность эти бины мало влияют. только на потребление памяти и скорость запуска приложения. если бин синглтон, то лежит он себе спокойненько в контексте, и никого не трогает.
AE
Ruslan Stelmachenko
Ну я вот только что проверил постманом. Может постман криво считает, конечно. Такие тесты не то, чтобы сильно научно правдивы. :)
Ну ок, железо разное, версии тоже, я замерял давно)
AE
Ruslan Stelmachenko
на производительность эти бины мало влияют. только на потребление памяти и скорость запуска приложения. если бин синглтон, то лежит он себе спокойненько в контексте, и никого не трогает.
+
C
Борис Селиверстов, если ты не бот, нажми "два". Ботов удалено: 398.
C
Маргарита Блохина, если ты не бот, нажми "два". Ботов удалено: 398.
C
Юганцева Андрон, если ты не бот, нажми "пять". Ботов удалено: 398.
C
Nikita, код неверный, обратись к админу.
2020 December 13
R
Ребят, вот пытаюсь написать запрос в репозитории, чтобы искать совпадение по query среди Thread.title и Messages.message.
Пытался написать такой
Page<ThreadEntity> findThreadEntitiesByTitleOrMessagesContains(@Param("titleOrMessage")String title, @Param("titleOrMessage")String messages, Pageable page);
Но он требует в качестве второго аргумента List<MessageEntity>. Можно ли это сделать как нибудь не используя нативный sql?
Пытался написать такой
Page<ThreadEntity> findThreadEntitiesByTitleOrMessagesContains(@Param("titleOrMessage")String title, @Param("titleOrMessage")String messages, Pageable page);
Но он требует в качестве второго аргумента List<MessageEntity>. Можно ли это сделать как нибудь не используя нативный sql?
AE
Ребят, вот пытаюсь написать запрос в репозитории, чтобы искать совпадение по query среди Thread.title и Messages.message.
Пытался написать такой
Page<ThreadEntity> findThreadEntitiesByTitleOrMessagesContains(@Param("titleOrMessage")String title, @Param("titleOrMessage")String messages, Pageable page);
Но он требует в качестве второго аргумента List<MessageEntity>. Можно ли это сделать как нибудь не используя нативный sql?
Пытался написать такой
Page<ThreadEntity> findThreadEntitiesByTitleOrMessagesContains(@Param("titleOrMessage")String title, @Param("titleOrMessage")String messages, Pageable page);
Но он требует в качестве второго аргумента List<MessageEntity>. Можно ли это сделать как нибудь не используя нативный sql?
...OrMessagesMessageContains
II
Как возвращать из замоканного объекта при вызове метода переданный аргумент?
when(valueRepository.save(v)).thenReturn(v);
Только чтобы вместо v был любой объект.
Пример проблемы:
Value v = new Value();
Value v2 = new Value();
when(valueRepository.save(v)).thenReturn(v);
В этом случае при вызове
valueRepository.save(v) - вернется v
valueRepository.save(v2) - вернется null
when(valueRepository.save(v)).thenReturn(v);
Только чтобы вместо v был любой объект.
Пример проблемы:
Value v = new Value();
Value v2 = new Value();
when(valueRepository.save(v)).thenReturn(v);
В этом случае при вызове
valueRepository.save(v) - вернется v
valueRepository.save(v2) - вернется null
PA
