Aditya, If we are doing a deep dive, one of the things to investigate would be memory/GC performance. IIRC, when I was looking into codahale at LinkedIn, I remember it having quite a few memory management and GC issues while using histograms. In comparison, histograms in the new metrics package aren't very well tested.
Thanks, Neha On Wed, Mar 25, 2015 at 8:25 AM, Aditya Auradkar < aaurad...@linkedin.com.invalid> wrote: > Hey everyone, > > Picking up this discussion after yesterdays KIP hangout. For anyone who > did not join the meeting, we have 2 different metrics packages being used > by the clients (custom package) and the server (codahale). We are > discussing whether to migrate the server to the new package. > > What information do we need in order to make a decision? > > Some pros of the new package: > - Using the most recent information by combining data from previous and > current samples. I'm not sure how codahale does this so I'll investigate. > - We can quota on anything we measure. This is pretty cool IMO. I've > investigate the feasibility of adding this feature in codahale. > - Hierarchical metrics. For example: we can define a sensor for overall > bytes-in/bytes-out and also per-client. Updating the client sensor will > cause the global byte rate sensor to get modified too. > > What are some of the issues with codahale? One previous discussion > mentions high memory usage but I don't have any experience with it myself. > > Thanks, > Aditya > > > > > -- Thanks, Neha
