|
|
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
sergq Дмитрий Мух Я бы начал не с кэширования, а с того, почему пул коннектов к базе выбирается. как вариант - резвый клиент. посмотрел по логу - 20 файлов "заказал" скачивать за 2 секунды. а файлы в базе.... Но. почему вчера до смены логики такого не было. хотя в логике просто убрался промежуточный слой 20 файлов за 2 секунды? Бот какой-то что-ли? Если до смены логики проблемы не было, то скорее всего вы сами что-то и сломали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 19:59 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
Дмитрий Мух Я бы начал не с кэширования, а с того, почему пул коннектов к базе выбирается. +, делать кеш привентивно -- плохая идея. Сначала нужно найти затык, кеш это один из инструментов повышения производительности, но единственный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:01 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
hVostt Дмитрий Мух пропущено... Блокировка чего и зачем? 1. Логика, которая приводит к изменениям данных 2. Инвалидируется кеш 3. Данные сохраняются в БД Между 2 и 3 другой клиент может выполнить запрос, который приведёт к заполнению кеша, уже не верными данными. Если просто на это взглянуть, то данные будут верные. Они ещё не попали в БД, после успешного сохранения в БД мы кладём актуальные данные в кэш. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:08 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
Дмитрий Мух Если просто на это взглянуть, то данные будут верные. Они ещё не попали в БД, после успешного сохранения в БД мы кладём актуальные данные в кэш. Между 2 и 3 кеш заполнится неверными данными при запросе через декоратор. Так как ты почистил его перед внесением изменений, а не после. Или я что-то не правильно понял в твоей схеме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:13 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
Дмитрий Мух после успешного сохранения в БД мы кладём актуальные данные в кэш И зачем класть в кеш, он же по запросу заполняется. Любые изменения сразу класть в кеш, такая себе схема по умолчанию. При таком подходе тебе всю БД 100% нужно кешировать, какой-то прогрев делать. Может не стоит этим заниматься раньше времени? ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:15 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
hVostt Дмитрий Мух после успешного сохранения в БД мы кладём актуальные данные в кэш И зачем класть в кеш, он же по запросу заполняется. Потому как Декоратор декарирует оба метода Репозитория: и Get, и Set. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:17 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
Дмитрий Мух Потому как Декоратор декарирует оба метода Репозитория: и Get, и Set. Set непонятно зачем делать без нужды? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:20 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
hVostt Дмитрий Мух Потому как Декоратор декарирует оба метода Репозитория: и Get, и Set. Set непонятно зачем делать без нужды? Точнее Set должен инвалидировать кеш после сохранения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:20 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
Дмитрий Мух, Да и откуда репозиторий знает что там и в каком виде лежит в кеше? Если будет знать, это большая связанность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:21 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
hVostt Любые изменения сразу класть в кеш, такая себе схема по умолчанию. Что же в ней не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:24 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
hVostt Дмитрий Мух Потому как Декоратор декарирует оба метода Репозитория: и Get, и Set. Set непонятно зачем делать без нужды? Да, не понятно зачем делать IRepository.Save(SomeEntity entity) без нужды :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:26 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
hVostt Дмитрий Мух, Да и откуда репозиторий знает что там и в каком виде лежит в кеше? Если будет знать, это большая связанность. Репозиторий не знает, Декоратор знает. Так что нет никакой связанности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:27 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
Дмитрий Мух hVostt Любые изменения сразу класть в кеш, такая себе схема по умолчанию. Что же в ней не так? Да всё не так. У меня 10 млн. пользователей в БД. Когда пользователь заходит в прилагу, для него установлены разные параметры, в том числе скидка. Это дело запрашивается в из БД и кладётся в кеш, чтобы использовать данные в разных сценариях без лишних запросов в БД. Потом заходит манагер и по случаю карантина всем скидос увеличивает на 10%. Т.е. у меня теперь у всех 10 млн. пользователей данные в кеш залезут при изменении? Нафига? ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:28 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
Дмитрий Мух hVosttSet непонятно зачем делать без нужды? Да, не понятно зачем делать IRepository.Save(SomeEntity entity) без нужды :) Метод инвалидируют все кеши, которые как-то зависят от SomeEntity. Например, по событию. Мне что в репо поддерживать все эти зависимости? Непонимать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:30 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
Ну и кеш однозначно отражает данные запроса. Если мне нужно обновить кеш при изменении, значит после выполненных изменений, мне нужно выполнить запрос, аналогичный Get. По сути, Set должен вызвать Get, чтобы он заполнил кеш. Нахрена оно мне упало, не все запросы на изменения предполагают автоматическое последующее чтение. А если я его итак буду делать, зачем мне это делать в Set? Какое-то избиение солид ногами. Я бы ещё понял, если было бы сделано намеренно для оптимизации конкретного сценария. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:34 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
hVostt Дмитрий Мух пропущено... Что же в ней не так? Да всё не так. У меня 10 млн. пользователей в БД. Когда пользователь заходит в прилагу, для него установлены разные параметры, в том числе скидка. Это дело запрашивается в из БД и кладётся в кеш, чтобы использовать данные в разных сценариях без лишних запросов в БД. Потом заходит манагер и по случаю карантина всем скидос увеличивает на 10%. Т.е. у меня теперь у всех 10 млн. пользователей данные в кеш залезут при изменении? Нафига? ) Стоп. Ты не разобравшись, начинаешь спорить. Декоратор над репозиторием при сохранении сущности обновляет только эту сужность в кэше. Когда происходят операции типа "по случаю карантина всем скидос увеличивает на 10%", тогда иначе. Например делаем, чтобы какой-то хэш в ключе кэширования сменился, следовательно по ключу в кэше уже ничего находится не будет и он заполнится актуальными данными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:35 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
Дмитрий Мух Стоп. Ты не разобравшись, начинаешь спорить. Декоратор над репозиторием при сохранении сущности обновляет только эту сужность в кэше. Когда происходят операции типа "по случаю карантина всем скидос увеличивает на 10%", тогда иначе. Например делаем, чтобы какой-то хэш в ключе кэширования сменился, следовательно по ключу в кэше уже ничего находится не будет и он заполнится актуальными данными. Окей. Значит Set за каким-то лезет в кеш и что-то там проверяет. Почему обычной инвалидации недостаточно? Она достаточно абстрактна и тебе пофигу что там в кеше лежит, по какому ключу, и может у тебя вообще 2 уровня кеша: локальный и распределённый. Во всех будешь ковыряться? ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:36 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
hVostt Дмитрий Мух пропущено... Да, не понятно зачем делать IRepository.Save(SomeEntity entity) без нужды :) Метод инвалидируют все кеши, которые как-то зависят от SomeEntity. Например, по событию. Мне что в репо поддерживать все эти зависимости? Непонимать. Какие зависимости в репо ты собрался поддерживать? Репо знает только то, что должен знать: как достать из хранилища и вызвать маппинг на SomeEntity. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:38 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
Дмитрий Мух, Ну и кеширование сущностей недостаточно. Кроме сущностей, могут быть различные проекции. Ты их не собираешься все обновить в своём репо? )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:38 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
Дмитрий Мух Какие зависимости в репо ты собрался поддерживать? Репо знает только то, что должен знать: как достать из хранилища и вызвать маппинг на SomeEntity. Непонятен профит. Зачем мне это делать в Set, если это прекрасно уже делается в Get. Заполнение кеша при чтении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:39 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
hVostt Дмитрий Мух Стоп. Ты не разобравшись, начинаешь спорить. Декоратор над репозиторием при сохранении сущности обновляет только эту сужность в кэше. Когда происходят операции типа "по случаю карантина всем скидос увеличивает на 10%", тогда иначе. Например делаем, чтобы какой-то хэш в ключе кэширования сменился, следовательно по ключу в кэше уже ничего находится не будет и он заполнится актуальными данными. Окей. Значит Set за каким-то лезет в кеш и что-то там проверяет. Почему обычной инвалидации недостаточно? Она достаточно абстрактна и тебе пофигу что там в кеше лежит, по какому ключу, и может у тебя вообще 2 уровня кеша: локальный и распределённый. Во всех будешь ковыряться? ) Давай примитивный пример репозитория: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. и примитивный пример декоратора: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:47 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
hVostt Дмитрий Мух Какие зависимости в репо ты собрался поддерживать? Репо знает только то, что должен знать: как достать из хранилища и вызвать маппинг на SomeEntity. Непонятен профит. Зачем мне это делать в Set, если это прекрасно уже делается в Get. Заполнение кеша при чтении. Ну к примеру не лепить блокировки :) Да и просто исключить лишнее обращение к БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:48 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
Дмитрий Мух, Чем хуже такой вариант? Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:50 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
Дмитрий Мух Ну к примеру не лепить блокировки :) Да и просто исключить лишнее обращение к БД. Ну ведь это только на самых банальных, чисто учебных примерах так. В реальных приложениях есть проекции данных, которые кешируются. Например, скидка, которая рассчитывается из множества данных, размещённых в разных агрегатах. Какой толк от этой реализации? Инвалидация нужна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:52 |
|
||
|
Вопрос по кешированию
|
|||
|---|---|---|---|
|
#18+
hVostt, ты прикалываешься? :) а зачем вообще кэшировать что-то, если оно вдруг никому не понадобится? обычно кэшируют то, что часто запрашивается и редко изменяется если что-то больше не понадобится, то будет вызван метод IRepository.Delete думаю ты легко догадаешься как он выглядит в RepositoryCacheDecorator ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2020, 20:55 |
|
||
|
|

start [/forum/topic.php?fid=33&msg=39946022&tid=1547108]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
60ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 176ms |

| 0 / 0 |
