Merge lp:~caravone/txstatsd/statsd-timings-consistency into lp:txstatsd
Proposed by
Curtis Caravone
Status: | Merged |
---|---|
Approved by: | Curtis Caravone |
Approved revision: | 56 |
Merged at revision: | 54 |
Proposed branch: | lp:~caravone/txstatsd/statsd-timings-consistency |
Merge into: | lp:txstatsd |
Diff against target: |
100 lines (+32/-9) 5 files modified
txstatsd/metrics/extendedmetrics.py (+4/-2) txstatsd/metrics/imetrics.py (+2/-2) txstatsd/metrics/metrics.py (+9/-4) txstatsd/metrics/timermetric.py (+1/-1) txstatsd/tests/test_metrics.py (+16/-0) |
To merge this branch: | bzr merge lp:~caravone/txstatsd/statsd-timings-consistency |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Sidnei da Silva | Approve | ||
Review via email:
|
This proposal supersedes a proposal from 2011-11-26.
Commit message
Added timing consistency (always take seconds but emit milliseconds) to ExtendedMetrics.
Added automatic timing option to ExtendedMetrics and signature of IMetrics timing methods.
Description of the change
Updated Nov. 28, 2011:
Made sure ExtendedMetrics and IMetrics had the updated timing() logic as well. Added unit tests for ExtendedMetrics.
Changed timing() method to clearly take durations in seconds and emit durations to txstatsd server in milliseconds
Add option for automatic calculation of timing duration
To post a comment you must log in.
Looks good. Thanks!
One thing I noticed is that we're storing instance-level attributes here and in other metrics. Which means that we can't safely use them from different threads. We need to make sure that we use a per-thread metrics object in client code, or maybe handle the thread-safety here so the client code doesn't have to bother.