Will open a PR in sometime. Thanks for looking into it. On Wed, Apr 16, 2025 at 6:12 PM hulk <hulk.webs...@gmail.com> wrote:
> > 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* >
