Azure Redis задержка кэширования

Question

Я работаю над приложением, имеющим веб-работу и приложение-функцию Azure.Веб-задание генерирует кэш redis для использования приложением-функцией.Размер кэша составляет около 10 мегабайт.Я использую ленивую загрузку и все согласно рекомендации.Я все еще нахожу, что общая операция кэширования медленная.В зависимости от размера файла, который я обрабатываю, я могу в итоге вызвать кэш Redis до 100 000 раз.Интересно, нужно ли мне хранить данные кеша в локальной переменной вместо того, чтобы читать их каждый раз из redis.Кто-нибудь испытывал какие-либо задержки при доступе к Redis?Имеет ли смысл создавать одиночный объект в приложении-функции c # и обновлять его на основе какого-либо таймера или другой логики?

Answer 1

Не могли бы вы учесть эти моменты при использовании? Это хорошая практика лазурного Redis Cashe

• Redis лучше всего работает с меньшими значениями , так что подумайте о том, чтобы нарезать большеданные в несколько ключей.В этом обсуждении Redis , 100kb считается "большим".Прочитайте эту статью для примера проблемы, которая может быть вызвана большими значениями.

• Используйте стандартный или премиальный уровень для производственных систем .Базовый уровень - это система с одним узлом без репликации данных и SLA.Также используйте как минимум кеш C1.Кэши C0 действительно предназначены для простых сценариев разработки / тестирования, поскольку они имеют общее ядро ​​ЦП, очень мало памяти, подвержены «шумному соседу» и т. Д.

• Помните, чтоRedis - это хранилище данных в памяти .так что вы знаете о сценариях, в которых может произойти потеря данных.

• Повторное использование соединений - Создание новых соединений стоит дорого и увеличивает задержку , поэтому повторно используйте соединения как можно чаще,Если вы решите создать новые подключения, не забудьте закрыть старые подключения перед их освобождением (даже на языках управляемой памяти, таких как .NET или Java).

• Найдите свой кэшэкземпляр и ваше приложение в одном регионе .Подключение к кешу в другом регионе может значительно увеличить задержку и снизить надежность.Подключение из-за пределов Azure поддерживается, но не рекомендуется, особенно при использовании Redis в качестве кэша (в отличие от хранилища ключей / значений, где задержка может быть не основной задачей).

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

• Настройте для maxmemory-reserved значениеулучшите быстродействие системы в условиях нехватки памяти, особенно для тяжелых нагрузок при записи или если вы храните большие значения (100 КБ или более) в Redis.Я бы порекомендовал начать с 10% размера вашего кеша, а затем увеличить, если у вас нагрузка при записи.См. некоторые соображения при выборе значения.

• Избегайте дорогих команд - Некоторые операции redis, такие как команда "KEYS", ОЧЕНЬ дорогии его следует избегать.

• Сконфигурируйте свою клиентскую библиотеку так, чтобы она использовала «тайм-аут соединения», по крайней мере, от 10 до 15 секунд , предоставляя системе время для подключения даже подболее высокие условия процессора.Если ваш клиент или сервер, как правило, находятся под высокой нагрузкой, используйте еще большее значение.Если вы используете большое количество подключений в одном приложении, рассмотрите возможность добавления некоторой разновидности логической схемы повторного подключения, чтобы предотвратить одновременное попадание потока на сервер.