Comments 8
Судя по ценам, если нужен кеш меньше 13ГБ дешевле взять виртуалку с линуксом и развернуть в ней redis самостоятельно (благодаря докеру это делается одной командой).
Для репликации понадобятся две виртуалки и немного почитать документацию — и все равно это будет дешевле.
Для репликации понадобятся две виртуалки и немного почитать документацию — и все равно это будет дешевле.
Согласен, что судя по ценам, которые мы видим на сайте, то 6Гб кеш можно соорудить из двух D2 linux серверов и сэкономить около $80 в месяц; аналог 2,5Гб кеш из двух D1 серверов, даст экономию $40 в месяц (цифры для стандарт версии). Но, нужно учитывать несколько важных моментов. Искользуя Azure Redis Cache у вас есть ряд приятных плюшек, таких как: мониторинг, настройки прав доступа, развёртывание в 3 клика и тп. Если посчитать время, которое потребуется админу на поднятие серверов и попытку соорудить что-то подобное возможностям Azure, то может оказаться, что игра не стоила свечь. И каждый раз когда нужно что-то промастабировать, изменить и т.п. мы опять будем бежать к админу и иметь завязку на человеческий фактор, который может болеть, быть занят и т.п. Так что тут решает каждый сам, что его важнее, сэкономить 50 баксов и потерять удобство и SLA или всё же переплатить и пользоваться всеми бенефитами инфраструктуры Azure.
«бенефитами», my ass. Пиджн-инглиш детектед! Лет ас нот микс лэнгвиджиз, ит лукс со агли! А по сути, согласен — каждый выбирает экономию либо удобство!
Да, не всегда мой русский является исконно русским. Сегодня многие английские слова так плотно входят в обиход, что далеко не сразу находятся русские аналоги. Но главное не скатываться до абсурда, как это было у меня в институте. Одного человека заставили на плакатах по защите диплома переводить слово cookies и на них жирно красовались слова «печеньки» и производные от них.
Ха-ха, точно, аналога кукисам в русском нет! ) вот в этом случае калька — единственный выход… А вообще Никитин как-то высказывался, что у них есть только мэйлы, а у нас письма и мэйлы. И друзья и френды вовсе не одно и то же ) Но в тех случаях, когда смысл равнозначен, я всё же голосую за использование устоявшихся обозначений, если они есть. А слово «преимущество» в русском уже есть )) А если хочется добавить англицизмов, хорошо смотрится использование кавычек. Переплатить и пользоваться всеми «бенефитами» инфраструктуры Azure. Ну, это личная точка зрения, конечно же )
UFO just landed and posted this here
Для начала, хотелось бы разобраться что такое кеш. Ведь реализация на основе ConcurrentDictionary это не совсем кеш. Одним из важных свойств любого кеша является возможность быть ограниченным по максимальному объёму занимаемой памяти. Для Dictionary-like реализаций это далеко не просто сделать. Можно конечно условно задать максимальное количество элементов в словаре, но мы всё равно можем добавить небольшое кол-во тяжёлых объектов и в итоге такая реализация будет попахивать утечкой памяти. Поэтому ответ будет скорее всего зависеть от ваших целей.
Если вы хотите гарантировать, что операция получения каждого дорогостоящего ресурса будет произведена не более одного раза (получили и положили в словарь), то вам вообще кеш не нужен и переходить на него не надо никогда.
Если всё-таки, ваша цель иметь кеш, то в первую очередь он должен быть реализован как кеш. Благо начиная с .Net 4.0 у нас появились ObjectCache и его прямой потомок MemoryCache, которые очень облегчают жизнь разработчика и дают готовую In-memory реализацию правильного кеша.
Далее, если мы говорим о переходе с MemoryCache на In-Role Cache (будь то co-located или dedicated), то преимуществ особо я не могу придумать. Максимум что приходит в голову, это более удобное планирование ресурсов (мы можем контролировать максимально возможный объём занимаемой памяти и размещение его в топологии нашей системы через конфигурационный файл нашего Cloud Service-a). Ещё, как по мне, декларативно выделенный кеш в виде отдельного компонента, выглядит более логичнее и проще для правильного конфигурирования. Так же, это может быть маленький шажочек на пути к горизонтальному масштабированию. Ведь если мы в Azure, то наверняка мы должны быть готовы к резкому увеличению нагрузки на систему и тогда, увеличивая количество экземпляров наших WebRole, мы должны иметь возможность сделать кеш общедоступным всем экземплярам. Иначе каждая роль будет иметь свой кеш, и ценность такого кеша будет падать (мы будем всегда читать более одного раза одно и тоже значение, даже если само значение только что вычитано, но наш балансировщик нагрузки направит запросы разным экземплярам WebRole), В случае с MemoryCache, хранимого в одной роли, добиться общедоступности будет сделать не просто.
Переход на Redis может так же дать какой-то выигрыш производительности за счёт специфики реализации самого Redis, плюс открыть возможности реализации например Publisher-Subscriber механизма.
Т. е. ещё раз повторюсь, всё зависит от того, что вы хотите в итоге получить и очень сложно дать дельный совет по вашему вопросу, не будучи знакомым с особенностями проекта.
Если вы хотите гарантировать, что операция получения каждого дорогостоящего ресурса будет произведена не более одного раза (получили и положили в словарь), то вам вообще кеш не нужен и переходить на него не надо никогда.
Если всё-таки, ваша цель иметь кеш, то в первую очередь он должен быть реализован как кеш. Благо начиная с .Net 4.0 у нас появились ObjectCache и его прямой потомок MemoryCache, которые очень облегчают жизнь разработчика и дают готовую In-memory реализацию правильного кеша.
Далее, если мы говорим о переходе с MemoryCache на In-Role Cache (будь то co-located или dedicated), то преимуществ особо я не могу придумать. Максимум что приходит в голову, это более удобное планирование ресурсов (мы можем контролировать максимально возможный объём занимаемой памяти и размещение его в топологии нашей системы через конфигурационный файл нашего Cloud Service-a). Ещё, как по мне, декларативно выделенный кеш в виде отдельного компонента, выглядит более логичнее и проще для правильного конфигурирования. Так же, это может быть маленький шажочек на пути к горизонтальному масштабированию. Ведь если мы в Azure, то наверняка мы должны быть готовы к резкому увеличению нагрузки на систему и тогда, увеличивая количество экземпляров наших WebRole, мы должны иметь возможность сделать кеш общедоступным всем экземплярам. Иначе каждая роль будет иметь свой кеш, и ценность такого кеша будет падать (мы будем всегда читать более одного раза одно и тоже значение, даже если само значение только что вычитано, но наш балансировщик нагрузки направит запросы разным экземплярам WebRole), В случае с MemoryCache, хранимого в одной роли, добиться общедоступности будет сделать не просто.
Переход на Redis может так же дать какой-то выигрыш производительности за счёт специфики реализации самого Redis, плюс открыть возможности реализации например Publisher-Subscriber механизма.
Т. е. ещё раз повторюсь, всё зависит от того, что вы хотите в итоге получить и очень сложно дать дельный совет по вашему вопросу, не будучи знакомым с особенностями проекта.
Sign up to leave a comment.
Azure cache