database: collect database performance metrics by default

[ehnuje]

Proposed changes

• Now database's read/write performance metrics are collected by default.
• --db.no-perf-metrics can be used to disable collecting the metrics.
• API to disable/enable collecting the metrics will be done in another PR.

Types of changes

Please put an x in the boxes related to your change.

• Bugfix
• New feature or enhancement
• Others

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING GUIDELINES doc
• I have signed the CLA
• Lint and unit tests pass locally with my changes ($ make test)
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in downstream modules

Related issues

• Please leave the issue numbers or links related to this PR here.

Further comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

[joowon-byun]

Just two questions.

1. Will there be a performance degradation, due to this PR?
2. This might not be relevant to this PR. What happens if meter.Mark() is called before metrics.NewRegisteredMeter()? Is this an error? I am curioused because the code always call in sequence like : newDatabaseManager() -> db.Meter(). I think initializing the meters should occur before newDatabaseManager or inside it.

[ehnuje]

Just two questions.

1. Will there be a performance degradation, due to this PR?

There is no performance degradation due to this PR.
Above figure is the one with this PR and the other one is the one without this PR.

2. This might not be relevant to this PR. What happens if meter.Mark() is called before metrics.NewRegisteredMeter()? Is this an error? I am curioused because the code always call in sequence like : newDatabaseManager() -> db.Meter(). I think initializing the meters should occur before newDatabaseManager or inside it.

Panic happens when calling to the nil reference. To avoid that case, dynamoBatchWriteTimeMeter and dynamoBatchWriteSizeMeter, static variables, are initialized by NilMeter, which does nothing when Mark is called. As Put/Get/BatchWrite operations can be done after returning dbManager object, I think it is okay with the current initialization sequences. How do you think? @winnie-byun

[joowon-byun]

If there is no performance degradation, why did you define DBNoPerformanceMetricsFlag?

[ehnuje]

If there is no performance degradation, why did you define DBNoPerformanceMetricsFlag?

@winnie-byun Because I'm uncertain that I've tested all the possible cases. If we won't see any performance degradation for reasonable period of time, we surely can remove the flag.