AR
Мб из-за параллельности
Size: a a a
2020 February 20
S
С чего это 40 были бы быстрее?
Параллельность - раз. Два - метод, который возвращает конкретные сущности на порядок проще оптимизировать и кешировать со своевременной инвалидацией/обновлением. Плюс у тебя пока ты не получишь все данные - нихрена не будет рисоваться, а так ты можешь по факту получения данных уже рисовать виджеты, что тоже сказывается на субъективном восприятии скорости загрузки данных
A
Мб из-за параллельности
40 запросов серверу + 40 ответов выполнятся быстрее, чем один? Бекенд то сбор данных тоже распараллеливает.
PT
40 запросов серверу + 40 ответов выполнятся быстрее, чем один? Бекенд то сбор данных тоже распараллеливает.
вообще то да
AR
40 запросов серверу + 40 ответов выполнятся быстрее, чем один? Бекенд то сбор данных тоже распараллеливает.
Если распаралелливает, то мб так же, но эффективно это вместе с кешированием для жирных запросов делать сложнее
Ещё это может быть не один бекенд
Ещё это может быть не один бекенд
PT
ну про 40 я конечно загнул
S
40 запросов серверу + 40 ответов выполнятся быстрее, чем один? Бекенд то сбор данных тоже распараллеливает.
есть часть данных, которая отдаётся за 5мс, есть часть данных, которой надо 250мс. Обе части придут через ~270мс. если в одном запросе. Всё это время фронт крутит прелоадер. Или за 5мс уже обновил данные в одном виджете, а ещё через 200 - в другом
AR
Это может быть 40 бекендов или 40 ядер, которым не нужен оверхед на синхронизацию и сериализацию финального ответа
AR
Так что ответ не очевиден и зависит от реализации
AR
По сути задачу мержа данных мы переносим на фронтенд
A
есть часть данных, которая отдаётся за 5мс, есть часть данных, которой надо 250мс. Обе части придут через ~270мс. если в одном запросе. Всё это время фронт крутит прелоадер. Или за 5мс уже обновил данные в одном виджете, а ещё через 200 - в другом
Это главная страница. Какие 250 мс? Данные подготовлены заранее.
PT
мои 5 копеек такие
сложные запросы заипешься кешировать лучше сделать 5 простых и положить в кеш потому что итоге будет макс 1 запрос в базу а остальное из кеша
сложные запросы заипешься кешировать лучше сделать 5 простых и положить в кеш потому что итоге будет макс 1 запрос в базу а остальное из кеша
A
мои 5 копеек такие
сложные запросы заипешься кешировать лучше сделать 5 простых и положить в кеш потому что итоге будет макс 1 запрос в базу а остальное из кеша
сложные запросы заипешься кешировать лучше сделать 5 простых и положить в кеш потому что итоге будет макс 1 запрос в базу а остальное из кеша
Никто не мешает кэшировать данные как угодно. У нас с этим трудностей нет. Всё разбито по SRP.
PT
Никто не мешает кэшировать данные как угодно. У нас с этим трудностей нет. Всё разбито по SRP.
да там больше проблема с инвалидацией
p
Параллельность - раз. Два - метод, который возвращает конкретные сущности на порядок проще оптимизировать и кешировать со своевременной инвалидацией/обновлением. Плюс у тебя пока ты не получишь все данные - нихрена не будет рисоваться, а так ты можешь по факту получения данных уже рисовать виджеты, что тоже сказывается на субъективном восприятии скорости загрузки данных
ну вот у нас 100500 посылок, мы хотим узнать для них статус. плодить 100500 параллельных запросов?