Firstly, thank you to the Redis teams for bringing a more powerful Redis and welcome version 7.4.
I deployed a redis cluster loading RediSearch.
When I execute the FT.SEARCH command, there will be a lot slow logs.
From my understanding, RediSearch uses a module client to call the other master redis to get the _ft.search result, and then aggreate them. The process of calling other redis does not block redis core, as I think, so the time spent on these calls should not be included in the command execution time. However, currently, this time is included, which easily results in slow logs (longer than 10ms).
Is my thoughts right or wrong? And whether there are any measures to avoid being counted in slow logs.
Thank you very much.
Comment From: sundb
@githubname1024 thanks, can you move the issue to https://github.com/RediSearch/RediSearch?
Comment From: githubname1024
@sundb Thank you for your reply. I have pasted the issue to RediSearch too.
Comment From: githubname1024
@sundb After consulting with the RediSearch team, I concluded that the module itself cannot determine how to calculate command execution time to ignoring the NIO time. And the command execution time directly affects the determination of slow log.
Are there any methods in Redis or its module API to optimize this?
For example, some options for excluding certain commands from being logged as slow queries, or for separating module commands into a distinct slow log, such as a 'module slow log'.
Thank you very much.
Comment From: githubname1024
@meiravgri @sundb Is there any previously mentioned method available? Or are there any other suggestions?
Comment From: sundb
@githubname1024 i don't have no idea now. IMHO, we can't consider a command is not slow command just because it's running in the background. can't you filter these module-related logs from slow logs?
Comment From: githubname1024
@sundb Thank you very much. I'll try to handle it another way.