Ваш кэш в Redis неэффективен, что с этим делать?

[n0isy]

Как мне кажется, можно memory bound операцию перевести в compute bound: хранить данные к примеру в Protocol Buffer формате, который много короче чем json. Следующий этап - сжимать

Таким образом смотреть за ростом cpu usage, чтобы добиться баланса между использованием процессора и памятью.

Про кеширование всего ответа - интересно, особенно если ответ сжимать gzip - браузеры нативно умеют запрашивать и обрабатывать такое.

[dph]

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

[gandjustas]

если output cache добавлять до response compression, то будут кэшироваться в памяти уже сжатые ответы. Естественно в этом случае обязательно vary by accept encoding как на клиенте, так и на сервере

Но чаще всего asp.net не публикуется напрямую в интернет, а прячется за прокси, и уже на прокси делается сжатие

[monco83]

FusionCache?

[gandjustas]

Хорошая библиотека, но она, по большей части, просто оборачивает memorycache и redis. redis в принципе не сильно полезен для кэширования, поэтому и не стал включать в статью.

[monco83]

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

Половину вашей боли библиотека решает: не нужно всякий раз делать round-trip до редиса, не нужно выкачивать громадную строку, не нужно сериализовать эту строку в модель. Остаётся только вторая половина проблема - сериализация этой модели в ответ HTTP. Насколько это в действительности проблема зависит от частоты запросов и размера хранимых данных. Допустим, что в вашем сценарии использования это действительно проблема. Но утверждать на этом основании, что "redis в принципе не слишком полезен для кэширования" - это слишком смелое обобщение.

[gandjustas]

Все полезное уже есть в asp.net - output cache решает проблему с cache stampede из коробки. При желании к нему можно прикрутить и redis, то тогда работать будет значительно медленнее. Можно redis storage заменить на fusion cache, но тогда вся суть будет в том, что ответ сервера будет также храниться в памяти.

Если мы берем не кэширование ответов asp.net, а кэш объектов, то MemoryCache может кэшировать объект без сериализации куда-либо, выдавая один и тот же экземпляр по запросу. FusionCache будет каждый раз сериализовывать.

FusionCache действительно содержит много кода и готовых решений, но найти сценарий где это превзойдет output cache или прямое использование MemoryCache - крайне сложно.

[monco83]

Раз вам сложно найти такой сценарий, то не буду спорить.

[andrew_tsw]

Обновление кэша в памяти через логическую репликацию - выглядит интересно. Но куда чаще видел вариант, когда изменения распространяется через pub/sub (тот же рredis).

Схема как в redis backplane - при изменении заказа один под пишет redis, остальные получают изменения чрез подписку на канал. Такой вариант не рассматривали?

[gandjustas]

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

Почему сброс через redis плох:

• не работает при массовом обновлении данных как из приложения, так и вне приложения через прямое выполнение sql. Для сброса надо получать ключи, а при массовом обновлении redis не знает какие ключи были обновлены. То есть вам все равно нужен будет какой-то механизм для сброса ключей при обновлении данных в базе.

• Если у вас уже есть база, в которой по сути встроен механизм для сброса, то зачем дополнительный сервер?

возникает вопрос почему redis так популярен, что его пихают во все сценарии, причин этому несколько:

1. Все хотят быть как бигтех, даже те кто никогда не станет бигтехом. У бигтеха скорее всего найдется сценарий где redis применим, а типичном saas на 10 000 - 100 000 запросов в час - нет.

2. Те кто рекомендуют использовать redis (Microsoft, amazon и итд) сами продают redis как сервис, им выгодно чтобы разработчики делали кэширование в redis.