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

Question

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

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

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

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

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

---

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

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

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

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

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

"Пожалуйста, попробуйте инкапсулировать алгоритм циклического перебора (имеющий 3/4/5 заводских экземпляров) в вашем синглтоне и сравните результаты нагрузочного теста."

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

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

---

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

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

Answer 1

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

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

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

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

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

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

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

Джейсон Рот

Answer 2

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

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

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

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

Я бы сказал одно: есть ли у вас возможность кэшировать «более короткие» объекты, чтобы вы могли делать меньше вызовов Get?Не могли бы вы кэшировать коллекции, а не отдельные объекты, а затем распаковывать коллекции на клиенте?700 кешей за загрузку страницы мне кажется огромным числом!