Comments 10
Интересно, что видимо обновился также и standalone AppFabric до 1.1.
Новый поставщик состояний сеансов поддерживает «ленивую» загрузку элементов состояния сеанса, используя Кэш AppFabric в качестве фонового хранилища. Это позволяет повысить производительность сайтов, где в сеансах хранятся крупные и мелкие элементы данных, так как страницы, на которых не используются крупные элементы состояния сеанса, не будут тратить время на их передачу по сети.
Так как кэш Windows Azure построен на AppFabric, то это нововведение аукнулось и в облаке.
Так как кэш Windows Azure построен на AppFabric, то это нововведение аукнулось и в облаке.
Или лыжи не едут или я туплю.
Вот есть у меня две веб роли (Веб1 и Веб2).
Первый запрос уходит в Веб1. Получаются данные по ключу КЛ. Они теперь в локальном кеше (HttpContext.Current.Items).
Второй запрос уходит в Веб2. Обновляются данные по ключу КЛ, удаляются из общего кеша.
Третий запрос уходит в Веб1. Получаются данные по ключу КЛ. Опа-па! Да они в локальном кеше есть! Берем из локального кеша (устаревшие некорректные данные).
На сколько я для себя понимаю распределенный кеш — он как раз и призван решать такую проблему. Т.е. когда мы из общего кеша удаляем данные, нам уже не важно, какая веб-роль будет обрабатывать запрос, все равно данные будут актуальные.
А в приведенном примере вообще непонятно, зачем общий кеш нужен? У каждой веб-роли получается есть свой собственный кеш. Разогреется он очень быстро, экономия на одном запросе, который промахнется мимо локально кеша, но зато попадет в распределенный кеш?
Вот есть у меня две веб роли (Веб1 и Веб2).
Первый запрос уходит в Веб1. Получаются данные по ключу КЛ. Они теперь в локальном кеше (HttpContext.Current.Items).
Второй запрос уходит в Веб2. Обновляются данные по ключу КЛ, удаляются из общего кеша.
Третий запрос уходит в Веб1. Получаются данные по ключу КЛ. Опа-па! Да они в локальном кеше есть! Берем из локального кеша (устаревшие некорректные данные).
На сколько я для себя понимаю распределенный кеш — он как раз и призван решать такую проблему. Т.е. когда мы из общего кеша удаляем данные, нам уже не важно, какая веб-роль будет обрабатывать запрос, все равно данные будут актуальные.
А в приведенном примере вообще непонятно, зачем общий кеш нужен? У каждой веб-роли получается есть свой собственный кеш. Разогреется он очень быстро, экономия на одном запросе, который промахнется мимо локально кеша, но зато попадет в распределенный кеш?
Честно говоря не понял про «не бесплатный».
Как явствует из описания, кэш выделяется на экземплярах веброли.
Т.е. оплачиваются исключительно инстансы, и какая разница сколько транзакций мы с ним совершим?
Как явствует из описания, кэш выделяется на экземплярах веброли.
Т.е. оплачиваются исключительно инстансы, и какая разница сколько транзакций мы с ним совершим?
Это скорее относится к первой версии кэша, так как раньше при его использовании, учитывалось количество транзакций.
Кэш у них безумно дорогой: за 128МБ больше ~1200р в месяц
Sign up to leave a comment.
Windows Azure: In-Memory Distributed Cache