> assigning unique keys to each test > case so that they’re fully independent and safe to run in parallel (using > t.Parallel() ).
I agree with this solution because reusing the same key across test cases is unnecessary. > And to the best of my knowledge each test has to also have its own redis client > and not use the global one The underlying of redis.client is a client pool indeed, so I guess it wouldn't impact the performance, but you can give it a shot. On Tue, 15 Apr 2025 at 21:49, Anirudh Lakhanpal < anirudhlakhanpal...@gmail.com> wrote: > Regarding: kvrocks issue <https://github.com/apache/kvrocks/issues/2642> > > Hello everyone, > > I've been looking into the execution time of the geo-related Go test cases > and noticed that they currently take around 150 seconds to run. I think > there's a good chance we can bring this down to 90–100 seconds by running > them in parallel. However, while digging into the tests, I realized that > many of them operate on the same keys, which makes parallelization tricky > due to potential data races. > > A straightforward way would be to use t.Parallel() for each test case but > this introduced issues related to the premature closing of the redis > client, and launching a separate client for each test case would be a bit > expensive. And since we cannot guarantee the order of execution of the > threads there is a high chance that a thread accessing a key is executed > first before the thread that creates the same key is executed, causing > errors. > > Another approach I tried was grouping test cases that use the same keys > into a single function, so that this function could run in parallel. But > since Go’s testing framework handles test execution and goroutines a bit > differently, I’m not entirely sure this is the right direction or if it > would be reliable. > > I’d like to suggest a cleaner solution: assigning unique keys to each test > case so that they’re fully independent and safe to run in parallel (using > t.Parallel() ). This should avoid key conflicts altogether and make it much > easier to scale the tests without worrying about race conditions. And to > the best of my knowledge each test has to also have its own redis client > and not use the global one > > > Would love to hear everyone's thoughts on this. > -- Best Regards, - *Hulk Lin*