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

Я ищу наиболее эффективный способ организации использования фабрики 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 создает соединение с серверами (например, .g если есть 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

 CRice11 нояб. 2010 г., 03:04
Теперь на форуме есть ответ на этот вопрос. Проверьте ссылку выше.

Ответы на вопрос(2)

Решение Вопроса

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

Не должно быть необходимости в более чем одном 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 ().

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

Джейсон Рот

 andrewbadera18 июн. 2011 г., 06:30
MaxConnectionsToServer - это мощный параметр конфигурации. Это обеспечивает параллелизм без явного кодирования того же самого. Обязательно реализуйте логику для перехвата DataCacheExceptions и ищите ErrorCode of RetryLater или Timeout для повторных попыток, поскольку конфликты могут возникать гораздо чаще.

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

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

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

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

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

 CRice27 сент. 2010 г., 01:01
Да, это огромное количество, но я добавляю провайдера кеширования для неприятной системы и не могу реально изменить основные требования к кешированию. Спасибо за ваши комментарии, все же это подчеркивает тот факт, что для моей конкретной проблемы не так много хорошей информации.
 PhilPursglove28 сент. 2010 г., 16:03
@Rohland Теги и регионы могут быть способом упростить часть кода за счет сокращения количества обращений в кэш. Готовьтесь, но я не уверен, что они дадут значительный выигрыш в производительности, так как я думаю, что код все еще будет тянуть то же самое количество элементов из кэша на страницу, т.е. я думаю, что вы все равно столкнетесь с теми же узкими местами.
 Rohland28 сент. 2010 г., 10:02
Что касается извлечения большого количества элементов из кэша, вы уже рассмотрели функциональность тегирования и региона? Если нет, прочитайте этот пост в блоге на эту тему:blogs.msdn.com/b/skaufman/archive/2010/04/22/...

Ваш ответ на вопрос