Comments 7
Не понимаю, чем предложенный вариант лучше вот этого.
А насчет
А насчет
Надеяться что любой тег проживет дольше записи помеченной этим тегом мне кажется слегка легкомысленным.можно сказать, что надеяться на любой кеш — вообще легкомысленно. Кеш — это непостоянное хранилище, которое может в любой момент оказаться пустым, и это нормально.
Не подходит потому что в варианте описанном в статье имеется вероятность получить не актуальные данные из кеша. Потому как при отсутствии тега в кеше, запись помеченная этим тегом считается валидной.
Такое может прокатить на башорге, на пример. Но на более серьёзном сайте такое может оказаться не простительным.
Не найти данных в кеше и получить не актуальные данные из кеша — это очень разные понятия.
Такое может прокатить на башорге, на пример. Но на более серьёзном сайте такое может оказаться не простительным.
Не найти данных в кеше и получить не актуальные данные из кеша — это очень разные понятия.
Насколько я понял — инверсией. В том варианте мы ок, когда «нету», а здесь — когда «есть». Этот вариант просто более валиден, а по сути — такой же.
А вообще я не понимаю другого — подобных подходов к кэшам. Кэш то он для чего? Чтобы процессор сидел и не напрягался лишний раз, чтобы диск крутился реже. А в таких случаях мы для того, чтобы в кэш сходить, должны поднажать, да в него же сходить, а потом ещё и расстроится :(
ззы: Идею то я понимаю. С идеологией не согласен :)
А вообще я не понимаю другого — подобных подходов к кэшам. Кэш то он для чего? Чтобы процессор сидел и не напрягался лишний раз, чтобы диск крутился реже. А в таких случаях мы для того, чтобы в кэш сходить, должны поднажать, да в него же сходить, а потом ещё и расстроится :(
ззы: Идею то я понимаю. С идеологией не согласен :)
У любого кеша есть свой оверхед, это надо понимать.
Если кешировать то, что можно и так получить из базы одним простым SELECT-ом, то разница в скорости скорее всего получится вообще отрицательной.
А вот для «тяжелых» рассчетов — это да, это оно.
Я кстати в одном проекте вообще запускаю наполнение кеша некоторых значений параллельно с основным потоком.
Если кешировать то, что можно и так получить из базы одним простым SELECT-ом, то разница в скорости скорее всего получится вообще отрицательной.
А вот для «тяжелых» рассчетов — это да, это оно.
Я кстати в одном проекте вообще запускаю наполнение кеша некоторых значений параллельно с основным потоком.
Мультигет нужен, вот что
Репозиторий есть? Давай я дополню
Репозиторий есть? Давай я дополню
Я разместил код в github.com/pvolyntsev/yii-cache-tag-dependency
Идея твоя, но код оптимизирован. Перевёл на английский и написал нормальные юнит тесты вместо var_dump(), которые неясно что возвращают.
Идея твоя, но код оптимизирован. Перевёл на английский и написал нормальные юнит тесты вместо var_dump(), которые неясно что возвращают.
Sign up to leave a comment.
Теггирование кеша в Yii