我们当前的缓存实现在报表对象中缓存大量数据(在某些情况下为 50MB)。
我们已经从内存缓存转移到文件缓存,并使用 ProtoBuf 进行序列化和反序列化。 这很有效,但是我们现在正在尝试使用 Redis 缓存。 下面是一个例子,说明 Redis 比使用文件系统需要多长时间。 (注意:在设置字节数组时,使用 protobuf 而不是 JsonConvert 将设置时间提高到 15 秒,在下面的示例中将获取时间提高到 4 秒)。
// Extremely SLOW – caching using Redis (JsonConvert to serialize/de-serialize)
IDatabase cache = Connection.GetDatabase();
// 23 seconds!
cache.StringSet("myKey", JsonConvert.SerializeObject(bigObject));
// 5 seconds!
BigObject redisResult = JsonConvert.DeserializeObject<BigObject>(cache.StringGet("myKey"));
// FAST - caching using file system (protobuf to serialize/de-serialize)
IDataAccessCache fileCache = new DataAccessFileCache();
// .5 seconds
fileCache.SetCache("myKey",bigObject);
// .5 seconds
BigObject fileResult = fileCache.GetCache<BigObject>("myKey");
预先感谢您的帮助。
ps。我没有从类似的问题中找到答案。 缓存大对象-LocalCache性能
或
Redis 实际上并不是为存储大对象(许多 MB)而设计的,因为它是一个单线程服务器。因此,一个请求会足够快,但少数请求会很慢,因为它们都将由一个线程处理。在最新版本中进行了一些优化。
RAM 的速度和内存带宽对于全局性能似乎不太重要,尤其是对于小对象。对于大对象(>10 KB),它可能会变得明显。通常,购买昂贵的快速内存模块来优化 Redis 并不划算。 https://redis.io/topics/benchmarks
因此,如果可能的话,您可以使用巨型帧或购买更快的内存。但实际上它不会有太大帮助。 考虑使用 Memcached 来代替。它是多线程的,可以水平扩展以支持大量数据。 Redis 只能通过主从复制来扩展。
从 Redis 6 开始,存在多路复用,虽然它保留了核心单线程数据访问接口,但 I/O 现在是线程化的。
否则你可以尝试“完全多线程”的 KeyDB