Add new SCRIPT STATS subcommand

[artikell]

An inspiration is needed to query the execution of the current script. Solve this problem https://github.com/orgs/valkey-io/discussions/1404

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.89%. Comparing base (4f61034) to head (b103f0f).
Report is 26 commits behind head on unstable.

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #1418      +/-   ##
============================================
+ Coverage     70.85%   70.89%   +0.03%     
============================================
  Files           118      118              
  Lines         63591    63627      +36     
============================================
+ Hits          45058    45108      +50     
+ Misses        18533    18519      -14     

Files with missing lines	Coverage Δ
src/commands.def	100.00% <ø> (ø)
src/eval.c	57.69% <100.00%> (+0.67%)	⬆️

... and 12 files with indirect coverage changes

[madolson]

Is the thought we will have more stats in the future? I'm wondering if we should just have a command just for the running script, instead of something generic like stats.

[artikell]

To be honest, this part is a reference to FUNCTION STATS.
Currently, there is really only one return value., but as a stat method, it is best to reserve the ability for subsequent extensions.
Alternatively, we can consider adding some Lua-related context, such as Lua execution time/ Lua use Memory, to help users locate problems.

[madolson]

Why the f$% did the Redis folks do this. I swear they barely thought through functions and then dumped it on the community.

[rjd15372]

@artikell thanks for your contribution. I'm not sure if it's worth to add a new command to just get the runtime duration of a script, since this can also be tracked by the application that executed the EVAL command.

Moreover, it's not clear to me how this new command solves the problem described in https://github.com/orgs/valkey-io/discussions/1404. Can you give us some more insights about it?

[artikell]

@artikell thanks for your contribution. I'm not sure if it's worth to add a new command to just get the runtime duration of a script, since this can also be tracked by the application that executed the EVAL command.

Moreover, it's not clear to me how this new command solves the problem described in https://github.com/orgs/valkey-io/discussions/1404. Can you give us some more insights about it?

I think when a developer finds that a valkey is blocked by lua, it needs a way to know which lua is blocking.

Using this command, users can be guided to locate the problem. Instead of just asking the user to kill the script

[rjd15372]

I think when a developer finds that a valkey is blocked by lua, it needs a way to know which lua is blocking.

Ah, I think I understand what you're trying to achieve here. You are not interested in the execution time of the script. What you are interested in is the name of the script being executed.

The name of an EVAL script is a SHA1 hash value. In order for it to be useful, you'll also need to track this hash value in your application to know exactly, which application script is being executed.
We actually trace in the server log the SHA1 of the script being executed when the server detects a slow execution of the script:

    serverLog(LL_WARNING,
              "Slow script detected: still in execution after %lld milliseconds. "
              "You can try killing the script using the %s command. Script name is: %s.",
              elapsed, (run_ctx->flags & SCRIPT_EVAL_MODE) ? "SCRIPT KILL" : "FUNCTION KILL", run_ctx->funcname);

I'm still not convinced about the usefulness of this new command, since there's always the need from the application side to keep track of the SHA1 -> script code association in order to know which scripting is being executed, and probably is much easier for the application to just log which scripting is currently being executed.

[artikell]

Ah, I think I understand what you're trying to achieve here. You are not interested in the execution time of the script. What you are interested in is the name of the script being executed.

Considering that the user can know the specific script through the script show command, there is no specific script information to be output here.

However, for a user who cannot view the log, he has no way of knowing the current running script name.