System.Web.Caching против блока кэширования корпоративной библиотеки

Это те элементы, которые я рассматриваю для темы кэширования:

MemCached Win32 Скорость .net кэш Блок Приложений Кэширования Корпоративной Библиотеки

MemCached Win32: до недавнего времени я использовал MemCached Win32. Это сродни веб-ферме (многие серверы обслуживают один и тот же контент для обеспечения высокой доступности), но это ферма кэша. Это означает, что вы можете установить его локально на вашем веб-сервере изначально, если у вас нет ресурсов для расширения. Затем, когда вы идете вниз по дороге, вы можете масштабировать горизонтально (больше серверов) или вертикально (больше оборудования). Это продукт, который был перенесен с оригинала MemCached на работу с Windows. Этот продукт широко используется на сайтах с очень высоким трафиком. http://lineofthought.com/tools/memcached

Скорость: это ответ Microsofts на такие продукты, как MemCached. MemCached уже довольно давно не работает, скорость находится в режиме CTP. Я должен сказать, что из того, что я прочитал до сих пор, этот продукт, безусловно, вскружит мне голову, как только он выйдет. Но я не могу заставить себя запустить большие производственные проекты на продукте CTP с нулевым послужным списком. Я начал играть с ним, хотя, как только он набирает обороты MemCached даже не сравнится с теми, кто заперт в мире windows! http://blogs.msdn.com/velocity/

.NET кэш: нет никаких причин сбрасывать со счетов стандартный .NET кэш. Он встроен и готов к использованию бесплатно и без какой-либо (основной) настройки требуется. Он обеспечивает гибкость, предлагая механизмы для хранения элементов в локальной памяти, сервере состояний SINGLE или централизованной базе данных. Где скорость шагает в том случае, когда вам нужно больше, чем один сервер состояния (кэш в памяти) и не хотите использовать медленную базу данных для хранения кэша.

Блок корпоративных приложений: я держусь подальше от всех блоков корпоративных приложений. Это тяжелые рамки, которые дают больше, чем я обычно требую! До тех пор, пока вы не забудете обернуть все, что касается кода, который не является вашим собственным, и следовать простым правилам кодирования, придерживайтесь любого из других методов поверх этого! (только мое мнение, конечно - MySpace использует столько, сколько они могут из корпоративных блоков приложений!)

Вам не нужно выбирать заранее! Обычно я создаю оболочку кэша, с которой взаимодействую в своем коде для таких методов, как Get, Set, Exists, Remove, ListKeys и т. д. Затем это указывает на базовый уровень абстракции кэша, который может указывать на MemCached, скорость или .NET кэш. Я использую StructureMap (или выбираю другой контейнер IoC), чтобы ввести форму кэша, которую я хочу использовать для данной среды. В моем локальном окне разработки я мог бы использовать кэш .NET в сеансе. В производстве я обычно использую MemCached Win 32. Но независимо от того, как он настроен, вы можете легко поменять местами вещи, чтобы попробовать каждую систему, чтобы увидеть, что лучше всего работает для вас. Вам просто нужно убедиться, что ваше приложение знает как можно меньше о том, как вещи кэшируются! После того, как этот уровень абстракции установлен, вы можете выполнить такие действия, как запуск алгоритма сжатия (gzip) для всех данных, поступающих в кэш и выходящих из него, что позволит вам хранить в 10 раз больше данных в кэше. - прозрачно .

Я покрываю .NET кэш, MemCached Win32, StructureMap и соответствующие абстракции в моей книге, Если вам интересно!

ASP.NET 3.5 социальная сеть ( http://www.amazon.com/ASP-NET-3-5-Social-Networking-Enterprise-ready/dp/1847194788/ref=sr_1_1?т. е.=UTF8&s=books&qid=1225408005&sr=8-1 ) Эндрю Симер www.andrewsiemer.com blog.andrewsiemer.com www.socialnetworkingin.net

Обновление изменило ссылку, которая перечисляет сайты, использующие memcached. Спасибо тебе, Дэвид, что заметил, что она сломана!

Имейте в виду, что документация EntLib специально направляет вас к ASP.NET кэшу для ASP.NET приложений. Это, вероятно, самая сильная рекомендация к использованию его здесь. Кроме того, кэш EntLib не имеет зависимостей, что для меня является большой причиной не использовать его.

Я не думаю, что существует такое техническое ограничение на доставку System.Web как часть вашего приложения, хотя немного странно, что они поместили это уведомление на странице .NET 3.5. Гензельман действительно говорит,что сначала он был напуган этой идеей, но потом убедился. Кроме того, если Вы читаете комментарии, он говорит, что блок имеет слишком много движущихся частей и Кэш ASP.NET гораздо более легкий.
Я думаю, что это именно та проблема, которую скорость собирается решить, но пока это только предварительный просмотр :-(

Я бы сказал использовать Web.Caching и посмотреть, как вы справитесь. Если вы поместите какой-то слой абстракции поверх него, у вас всегда есть возможность поменять его на блок EntLib позже, если вы обнаружите проблемы.

Взгляните на memcached . Это действительно классная, быстрая и легкая распределенная система кэширования. Существует APIs для нескольких наиболее популярных языков, в том числе C#. он может плохо работать на стороне клиента (если, конечно, клиент не получает кэшированные данные с какого-либо сервера), но если вы абстрагируете свое использование memcached на определенный интерфейс, вы можете затем реализовать интерфейс с другой системой кэширования.

@Davide вости

"Если они поместили его в веб-пространство имен, я думаю, что это не просто так." Применима ли та же логика к среде выполнения параллелизма и координации (CCR) в роботизированной студии? - нет? но я так не думаю.