Кэширование AppFabric - правильное использование DataCacheFactory и DataCache

Я ищу наиболее эффективный способ организовать использование datacache и datacache factory для вызовов кэширования AppFabric, так как от 400 до 700 кэшей загружается на каждую страницу (и практически без каких-либо пометок). Похоже, что использование одного статического DataCacheFactory (или, возможно, пара в круговой настройке) - это путь.

Я вызываю GetCache ( "cacheName" ) для каждого запроса объекта DataCache или могу сделать один статический файл в момент инициализации DataCache factory и использовать его для всех вызовов?

Нужно ли обрабатывать исключения, проверять коды сбоев и повторять попытки?

Должен ли я рассматривать конкуренцию, когда более одного потока пытается использовать хранилище кеша и хочет тот же элемент (по ключу)?

Есть ли какая-то документация, которая должным образом исследует дизайн и использование этого?

Некоторая информация, которую я собрал до сих пор от форума:

http://social.msdn.microsoft.com/Forums/en-AU/velocity/thread/98d4f00d-3a1b-4d7c-88ba-384d3d5da915

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

http://social.msdn.microsoft.com/Forums/en-US/velocity/thread/0c1d7ce2-4c1b-4c63-b525-5d8f98bb8a49

"Создание единого DataCacheFactory (singleton) более эффективно, чем создание нескольких DataCacheFactory. Вы не должны создавать DataCacheFactory для каждого вызова, у него будет удар производительности".

"Пожалуйста, попробуйте инкапсулировать алгоритм round-robin (с 3/4/5 factory экземплярами) в вашем singleton и сравнить результаты теста нагрузки".

http://blogs.msdn.com/b/velocity/archive/2009/04/15/pushing-client-performance.aspx

"Вы можете увеличить количество клиентов, чтобы увеличить пропускную способность кеша. Но иногда, если вы хотите иметь меньший набор клиентов и увеличить пропускную способность, трюк заключается в использовании нескольких экземпляров DataCacheFactory. Экземпляр DataCacheFactory создает соединение с серверами (e..g, если есть 3 сервера, он будет создавать 3 соединения) и мультиплексирует все запросы из datacaches на эти соединения. Поэтому, если уровень put/get очень высок, эти TCP-соединения могут быть узкими. является создание нескольких экземпляров DataCacheFactory, а затем использование операций над ними."

Здесь то, что используется до сих пор... вызывается свойство и если возвращаемое значение не равно нулю, выполняется операция.

private static DataCache Cache
{
    get
    {
        if (_cacheFactory == null)
        {
            lock (Sync)
            {
                if (_cacheFactory == null)
                {
                    try
                    {
                        _cacheFactory = new DataCacheFactory();
                    }
                    catch (DataCacheException ex)
                    {
                        if (_logger != null)
                        {
                            _logger.LogError(ex.Message, ex);
                        }
                    }
                }
            }
        }

        DataCache cache = null;

        if (_cacheFactory != null)
        {
            cache = _cacheFactory.GetCache(_cacheName);
        }

        return cache;
    }
}

Смотрите этот вопрос на форуме Microsoft AppFabric: http://social.msdn.microsoft.com/Forums/en-AU/velocity/thread/e0a0c6fb-df4e-499f-a023-ba16afb6614f

Ответ 1

Вот ответ на сообщение в форуме:

Привет. Извините за задержку ответа, но я хочу сказать, что они великолепны вопросы и, вероятно, будут полезны другим.

Не нужно больше чем один DataCacheFactory за поток если вам не нужны разные конфигурации. Например, если вы программно настроить DataCacheFactory с Класс DataCacheFactoryConfiguration, то вам может понадобиться создать имеет локальный кеш включен, а другой это не. В этом случае вы использовать различные объекты DataCacheFactory в зависимости от конфигурации вы требуется для вашего сценария. Но другие чем различия в конфигурации, вы не должны видеть прирост производительности создавая несколько DataCacheFactories.

По тому же вопросу есть Настройка MaxConnectionsToServer (либо программный DataCacheFactoryConfiguration или в файл конфигурации приложения как атрибут dataCacheClient элемент). Это определяет число из ченнелей в DataCacheFactory, что открываются кластеру кэша. Если у вас высокие требования к пропускной способности а также доступный CPU/Network пропускной способности, увеличивая этот параметр до 3 или выше, может увеличить пропускную способность. Мы не рекомендуем увеличивать это без причины или для значения, которое слишком высока для ваших нужд. Вам следует измените значение, а затем проверьте сценарий для наблюдения за результатами. Мы надеемся получить больше официальных указаний по это в будущем.

Как только у вас есть DataCacheFactory, вы не нужно вызывать GetCache() несколько раз, чтобы получить несколько Объекты DataCache. Каждый звонок GetCache() для того же кеша на тот же factory возвращает то же самое Объект DataCache. Кроме того, как только вы объект DataCache, вам не нужен продолжить вызов DataCacheFactory для этого. Просто сохраните DataCache объект и продолжать использовать его. Однако не позволяйте Объект DataCacheFactory удаляется. Срок службы объекта DataCache привязан к объекту DataCacheFactory.

Вам никогда не придется беспокоиться о конфликт с запросами Get. Однако, с помощью запросов "Путь/добавление", может быть если несколько кешей данных клиенты обновляют один и тот же ключ в в то же время. В этом случае вы будете получить исключение с кодом ошибки ERRCA0017, RetryLater и подстанция ES0005, KeyLatched. Однако вы может легко добавлять обработку исключений и повторить логику, чтобы попытаться обновить снова, когда возникают такие ошибки. Это можно сделать для кодов RetryLater с различными значениями подвалов. Для больше информации, см. http://msdn.microsoft.com/en-us/library/ff637738.aspx. Вы также можете использовать пессимистическую блокировку используя GetAndLock() и API PutAndUnlock(). Если вы используете это метод, вы несете ответственность за убедитесь, что все клиенты кеша используют пессимистическая блокировка. Вызов "Путь" () будет уничтожить объект, который был ранее заблокирован GetAndLock().

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

Джейсон Рот

Ответ 2

Я вызываю GetCache ( "cacheName" ) для каждый запрос объекта DataCache, или Я делаю один статический в то время DataCache factory инициализируется и использовать это для всех вызовов?

Я полагаю, что действительно должен быть ответ; попробуйте в обоих направлениях и посмотрите, есть ли разница, но один статический DataCache кажется мне более разумным, чем соответствующий вызов GetCache для каждого вызова Get.

Эта статья "Нажатие производительности клиента" указывает на то, что там есть место, где число экземпляров DataCacheFactory достигает максимальной производительности, за пределами которой накладные расходы на память начинают работать против вас - стыдно, что они не дали никаких рекомендаций (или даже эмпирическое правило), где это место может быть.

Я не сталкивался с какой-либо документацией по максимизации производительности - я думаю, AppFabric все еще слишком нов для того, чтобы эти рекомендации были еще потрясены. Я посмотрел в Содержание для Pro AppFabric book, но, похоже, он в большей степени относится к стороне рабочего процесса (Dublin) AppFabric чем часть кеширования (Velocity).

Одна вещь, которую я бы сказал, есть: есть ли у вас возможность кэшировать объекты "chunkier", чтобы вы могли сделать меньше вызовов Get? Можете ли вы кэшировать коллекции, а не отдельные объекты, а затем распаковывать коллекции на клиенте? 700 кэшей на загрузку страницы кажется мне огромным!