zodb / perfmetrics Goto Github PK

Currently, a library author decorates their code with things like @Metric(rate=0.1) to specify a 10% capture rate. If a user of that library wants to set a different capture rate, they're out of luck.

A rough workaround is to have the library author introduce a level of abstraction, for example an environment variable:

rate = float(os.environ.get('SAMPLE_RATE', '0.1'))

class Foo:
    @Metric(method=True, rate=rate)
    def thing(self): 
        pass

That gets complicated quick if you want to allow for different rates on the same object or module, etc.

Idea: Let a user directly manipulate the parameters after applying the decorator:

from library import Foo
Foo.thing.rate = 0.5

(Bonus points: have this library maintain a registry of known metrics, and allow retrieving the Metric object by name --- allowing for multiples.)

This would mean that the closure (call_with_metric) that's capturing the parameters and wrapping the decorated object would need to become a more active object. When it's used in a class, being a descriptor would be a good way to allow customization while still preserving speed.

This repo is licensed under the Repoze (BSD-derived) license. We should state that clearly with a LICENSE file.

Statsd supports a Set metric type for "... counting unique occurences of events between flushes ...". The existing statsd client implemented here doesn't provide a public method suitable for sending metrics of this type. Would you be willing to accept a PR implementing this functionality?

This would be needed for #8. Some non-RST formatting has crept in to some of the files.

Especially Windows wheels. There are appveyor examples we can snag from elsewhere.

Including 2.0.

The tests fail with this version. I suspect it mostly works in practice, but the output has changed.

In tox.ini, and in .travis.yml through coveralls.

This surprised me today. I changed an interface signature and expected test failures to alert me that the implementations no longer correctly implemented the method (because I hadn't updated their signatures yet). But that didn't happen. It turns out that the call_with_metric wrapper that's being returned from the decorator takes *args, **kwargs and that's enough to break signature introspection as far as zope.interface is concerned.

Interestingly, it doesn't break signature display as far as IPython is concerned.

I'm not sure there's anything much we can do here other than document this.

I'm thinking we can probably just integrate nti.fakestatsd right into this project in perfmetrics/testing.

The license on nti.fakestatsd was different (Apache) but since we (@NextThought) wrote that code, we can relicense it easy enough.

• Configure a repository secret for upload
• Badge and any other links

It defines __len__ and is thus falsey until a packet has been sent. But it's common for client code to write if statsd_client(): ..., leading to branches getting missed.

This would potentially be a breaking change for existing tests, so perhaps this should go in a subclass.

ETA: I doubt that's much of an issue, and I don't want to perpetuate the difference between the testing class and the other classes.

Trying to install the Linux wheel for Relstorage 3.0.0 fails because permetrics release 3.0.0 contains only wheels for Windows and Mac.

To reduce the overhead of the decorators.

We'd need to benchmark to see if its worthwhile.