![]() I don't know what you did incorrectly in 1.x and fixed in 2.x. We used the performance profiler in VS before but couldn't find anything useful. And redis is heavily used here when processing a request. They are in the same load balancer with same work load. These instances are processing live requests. What I can tell you is this is not stress test. It is very hard to quantify how much work is redis. But please trust me that we did lots of testing and got the similar result. This graph might not be the best example. other processes here, so that information would help give a picture as well. I'm not sure how much of your cluster work is Redis vs. The goal is to minimize that though, and any information you can provide there is very helpful (including traces or profiling).Īt the moment (latest prerelease) when the only workload in a process is Redis we expect to see a ~5% difference in CPU (of the process, not e.g. Overall: what are these doing? Are they processing the same number of requests/commands? Similar of different latencies? To be clear: we expect there to be some CPU difference when changing to 2.x, because 1.2.6 did somethings incorrectly and there's a bit of increase cost in doing them correctly consistently. It was because even a small clue was needed to increase the I see, in the graph I'm confused about the "always lower" due to the 11:05 to 12:00 section of that graph where they almost match, seems like there's some jitter between. This is a problem I am experiencing while making a new dotnet5, but I am using redis a lot, so I wrote it here. The reason I said vaguely above is because there was no change in tps.Īnyway, I'm trying to see the whole thing. I think light work is being handled heavily. I think I'll have to look at the async await or the web client part one by one. ![]() I'm thinking it might not be 100% redis problem. When I stress test, the CPU usage is always close to 100%. When I checked the performance with the tool, the redis call does not come out properly. Return redisValues.Select(redisValue => TryAutoConvertToValue(redisValue, _config.RedisValueType).Item2).Where(v => v != The api server I'm building now doesn't do heavy work. Var redisValues = await _(keys.Select(k => (RedisKey)FormatKey(k, _redisConnection.ReadKeyType)).ToArray()).ConfigureAwait(false) Public async Task> GetListAsync(List keys, CacheGetOptions options = null) Server = connection.GetServer((','), DefaultPort) Ĭonnection.ErrorMessage += Connection_ErrorMessage Ĭonnection.InternalError += Connection_InternalError ĭatabase = connection.GetDatabase(redisConnectionString.OperateDb) Private void InitConnection(RedisConnectionString redisConnectionString, out ConnectionMultiplexer connection, out IDatabase database, out IServer server)Ĭonnection = ConnectionMultiplexer.Connect(redisConnectionString.ConnectionString) Only one database will be created for a redis instance. _redisConnection = new RedisConnection(_config) Public RedisCacheClient(CacheClientConfig config) What is so strange is that we replicate this issue in difference services and yet didn't find anyone reporting this issue over the internet. So this is what we suspect that caused the perofrmance issue. After reading the release note, we noticed that one of the biggest changes for 2.x is that it uses. We did some performance testing using performance profiler in VS but didn't find anything useful. Yesterday we did it again using the latest version 2.2.79, but the result is the same. Rough number is 70% vs 60%, which is pretty bad. After running it for a while, we see that CPU of these 5 machines are higher than the other 15. For testing purpose, we upgraded and deployed 5 machines under 2.x. We have a service running in a cluster of 20 machines. We did some testing, then ran into the performance issue. 2 months ago, we decided to upgrade to 2.x. We had been using 1.2.6 for quite some time.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |