Эффективность методов сохранения для большого кеша asp.net

Question

Любопытно, если у кого-то есть мнения о том, какой метод лучше подходит для кэширования asp.net. Вариант первый: иметь меньше элементов в кэше, которые являются более сложными, или множество элементов, которые являются менее сложными.

Ради обсуждения давайте представим, что на моем сайте есть объекты SalesPerson и Customer. Это довольно простые классы, но я не хочу болтать с базой данных, поэтому я хочу лениво загружать их в кеш и делать недействительными их из кеша, когда я делаю изменения - достаточно просто.

Вариант 1 Создать словарь и кэшировать весь словарь. Когда мне нужно загрузить экземпляр SalesPerson из кэша, я вынимаю словарь и выполняю обычный поиск ключа по словарю.

Вариант 2 Префикс ключа каждого элемента и сохранить его непосредственно в кэше asp.net. Например, каждый экземпляр SalesPerson в кеше будет использовать составную часть префикса плюс ключ для этого объекта, поэтому он может выглядеть как sp_ [guid] и храниться в кеше asp.net, а также в кеше находятся объекты Customer с ключ как cust_ [guid].

Один из моих опасений, связанных со вторым вариантом, заключается в том, что число записей будет очень большим, между SalesPerson, Customer и дюжиной или около того другими категориями. У меня может быть 25K элементов в кеше и повторяющиеся поиски чего-то вроде строкового ресурса, который Я использую в нескольких местах может заплатить штраф, в то время как код просматривает коллекцию ключей кэша, чтобы найти его среди других 25K.

Я уверен, что в какой-то момент здесь наблюдается уменьшение отдачи от хранения слишком большого количества элементов в кэше, но мне любопытно узнать мнение по этим вопросам.

Answer 1

Лучше создавать в кеше множество мелких предметов, чем создавать меньше, крупнее. Вот рассуждение:

1) Если ваши данные небольшие, то количество элементов в кеше будет относительно небольшим и не будет иметь никакого значения. Извлечение отдельных объектов из кэша проще, чем выбор словаря, а затем выборка элемента из этого словаря.

2) Как только ваши данные станут большими, кеш можно использовать для интеллектуального управления данными. Объект HttpRuntime.Cache использует алгоритм наименьшего числа недавно использовавшихся (LRU), чтобы определить, какие элементы в кэше должны истечь. Если у вас есть только небольшое количество часто используемых элементов в кэше, этот алгоритм будет бесполезен. Однако, если у вас есть много меньших элементов в кэше, но 90% из них не используются в данный момент (очень распространенная эвристика использования), то алгоритм LRU может гарантировать, что те элементы, которые активно используются, остаются в кэше выселяя менее использованные предметы, чтобы обеспечить достаточно места для использованных предметов.

По мере роста вашего приложения важнее всего будет иметь возможность управлять тем, что находится в кеше. Кроме того, я еще не видел какого-либо снижения производительности из-за наличия миллионов ключей в кеше - хеш-таблицы чрезвычайно быстры, и если вы обнаружите там проблемы, их, вероятно, легко решить, изменив соглашения об именах для ключей кеша, чтобы оптимизировать их для использования в ключи хеш-таблицы.

Answer 2

ASP.NET Cache использует свой собственный словарь, поэтому использование его словаря для поиска вашего словаря для поиска ваших объектов кажется неоптимальным. Словари используют хеш-таблицы, что является наиболее эффективным поиском, который вы можете сделать. Я думаю, что использование ваших собственных словарей добавит больше накладных расходов. Я не знаю об уменьшении возврата в отношении хеш-таблиц, но я думаю, что это будет с точки зрения размера хранилища, а не времени поиска.

Я бы заинтересовался тем, что облегчает вашу работу. Если более организованный кэш сделает ваше приложение более легким для понимания, отладки, расширения и обслуживания, я бы сделал это. Если это усложнит ситуацию, я бы этого не сделал.

И, как упоминалось в nullvoid, все это предполагает, что вы уже исследовали более крупные последствия кэширования, которые включают измерение прироста производительности по сравнению с падением производительности. Вы говорите о хранении большого количества объектов, а это подразумевает большой трафик кеша. Я бы сохранил в кеше только то, что вы можете измерить прироста производительности от этого.

Answer 3

Мы создали приложение, которое использует Caching для хранения всех ресурсов. Приложение мультиязычное, поэтому для каждого ярлыка в приложении у нас есть как минимум три перевода. Мы загружаем комбинацию (Label, Culture), когда это необходимо, а затем удаляем ее из кэша, только если она была изменена администратором в базе данных. Этот сценарий работал отлично, даже когда в кеше было 100000 элементов. Мы позаботились только о том, чтобы настроить кэш и политики истечения срока действия таким образом, чтобы нам действительно было выгодно использовать кэш. Мы используем no-expiration, поэтому элементы кэшируются до тех пор, пока рабочий процесс не будет сброшен или пока элемент не будет намеренно истек. Мы также позаботились о том, чтобы определить домен для значений ключей таким образом, чтобы однозначно идентифицировать метку в конкретной культуре с наименьшим количеством символов.

Answer 4

Я собираюсь предположить, что вы рассмотрели все последствия изменения данных от нескольких пользователей и как это повлияет на кэшированные данные с точки зрения обработки противоречивых данных. Кэширование действительно предназначено только для статических данных.

С точки зрения эффективности я бы предположил, что, если вы правильно используете сериализацию .net, вы выиграете от хранения данных в кеше в виде более типизированных сериализованных коллекций, а не отдельных базовых типов.

С точки зрения обслуживания это также будет лучшим подходом, так как вы можете создать строго типизированный объект для представления данных и использовать сериализацию для приведения их между кэшем и вашим продавцом / клиентом.