git-hulk commented on PR #3557:
URL: https://github.com/apache/kvrocks/pull/3557#issuecomment-5022131207
> > @nhancdt2602 It seems only the calls/latency are related to the
namespace, so I'm wondering if it's better to extend the existing functions in
`stats`:
> > ```c++
> > void IncrCalls(const string &ns, const string &cmd) {
> > stats->total_calls++;
> > if (ns != kDefaultNamespace) {
> > stats->ns_command_calls[ns]++;
> > }
> > }
> > ```
> >
> >
> > so that we don't need to intercepting the stats and namespace in serval
places. cc @jihuayu @PragmaTwice
>
> Thanks @git-hulk for your review. I saw your point about moving the
namespace resolution logic into stats fields/methods like `IncrCall`,
`IncrLatency` or `commands_histogram`. The reason I resolve the namespace at
the caller layer rather than inside `IncrCalls/IncrLatency` is to keep the
command hot path lock-free.
>
> I want to keep the overhead of adding namespace telemetry information as
minimal as possible. By keeping the namespace stats pointer when a connection
is established, we are free of lock when accessing the namespace stat entry.
>
> That said, if you and project members prefer consolidating into Stats,
accepting a per-command lock. I'm happy to refactor that way; just let me know
the preferred trade-off.
>
> I'd love to hear your opinion about this ^^
@nhancdt2602 I'm not sure how much performance would be impacted.
Consolidating into one stats would be more consistent from my personal
perspective since only a few metrics are related to the namespace.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
