Мне повезло, что я переключился с JSON на Protobuf ser / de, используя пакет Protobuf-net . Но, похоже, даже если это сократит его до часто повторяемого в 6 раз более быстрого времени выполнения, время десериализации в 20 секунд, вероятно, все равно не сократит его в этом случае - поскольку вся цель состоит в том, чтобы кэшировать его для конкретного пользователя для «короткий» период времени.
Это звучит как классический случай нетерпеливой и ленивой загрузки. Поскольку вы уже используете Redis, рассматривали ли вы отдельно кэширование каждого свойства объекта как отдельного ключа? Чем больше свойств и, следовательно, чем меньше каждый из них, тем более полезной будет эта стратегия. Конечно, я предполагаю довольно ортогональный набор свойств объекта - если многие из них имеют зависимости друг от друга, то это, вероятно, будет работать хуже. Но если в шаблонах доступа обычно не требуется весь гидратированный объект, вы можете значительно улучшить отзывчивость, выбирая требуемое индивидуальное свойство вместо всего объекта.
Я предполагаю многое о вашем объекте, но самым простым шагом было бы реализовать средство доступа get каждого свойства для выполнения вызова Redis Get. У этого есть много других недостатков, касающихся управления зависимостями и многопоточного доступа, но это может быть простой способ получить подтверждение концепции.
Имейте в виду, что это значительно усложняет требования к аннулированию кэша. Даже если вы можете хранить каждое свойство отдельно в Redis, если вы затем сохраните это значение в переменной на каждой машине после выборки, вы быстро столкнетесь с ситуацией неуправляемого кэша, где вы не сможете гарантировать синхронизированные данные в зависимости от того, какая машина обслуживает следующий запрос.