far, I'm +1 for migrating to KM.
Thanks,
Aditya
From: Jun Rao [j...@confluent.io]
Sent: Sunday, March 29, 2015 9:44 AM
To: dev@kafka.apache.org
Subject: Re: Metrics package discussion
...@confluent.io]
Sent: Sunday, March 29, 2015 9:44 AM
To: dev@kafka.apache.org
Subject: Re: Metrics package discussion
There is another thing to consider. We plan to reuse the client
components
on the server side over time. For example, as part of the
security
work
From: Jun Rao [j...@confluent.io]
Sent: Sunday, March 29, 2015 9:44 AM
To: dev@kafka.apache.org
Subject: Re: Metrics package discussion
There is another thing to consider. We plan to reuse the client
components
on the server side over time. For example, as part
numbers.
Based on the arguments so far, I'm +1 for migrating to KM.
Thanks,
Aditya
From: Jun Rao [j...@confluent.io]
Sent: Sunday, March 29, 2015 9:44 AM
To: dev@kafka.apache.org
Subject: Re: Metrics package discussion
There is another
: Re: Metrics package discussion
There is another thing to consider. We plan to reuse the client
components
on the server side over time. For example, as part of the security
work, we
are looking into replacing the server side network code with the
client
network code
:44 AM
To: dev@kafka.apache.org
Subject: Re: Metrics package discussion
There is another thing to consider. We plan to reuse the client
components
on the server side over time. For example, as part of the security
work, we
are looking into replacing the server side network code
@kafka.apache.org
Subject: Re: Metrics package discussion
There is another thing to consider. We plan to reuse the client components
on the server side over time. For example, as part of the security work, we
are looking into replacing the server side network code with the client
network code (KAFKA-1928
: Jun Rao [j...@confluent.io]
Sent: Sunday, March 29, 2015 9:44 AM
To: dev@kafka.apache.org
Subject: Re: Metrics package discussion
There is another thing to consider. We plan to reuse the client components
on the server side over time. For example, as part of the security work, we
are looking
for migrating to KM.
Thanks,
Aditya
From: Jun Rao [j...@confluent.io]
Sent: Sunday, March 29, 2015 9:44 AM
To: dev@kafka.apache.org
Subject: Re: Metrics package discussion
There is another thing to consider. We plan to reuse the client components
thread on this once we have a
couple more opinions.
Thanks,
Aditya
From: Jay Kreps [jay.kr...@gmail.com]
Sent: Thursday, March 26, 2015 2:29 PM
To: dev@kafka.apache.org
Subject: Re: Metrics package discussion
Yeah that is a good
@kafka.apache.org
Subject: Re: Metrics package discussion
Yeah that is a good summary.
The reason we don't use histograms heavily in the server is because of
the
memory issues. We originally did use histograms for everything, then we
ran
into all these issues, and ripped them out. Whether
]
Sent: Thursday, March 26, 2015 2:29 PM
To: dev@kafka.apache.org
Subject: Re: Metrics package discussion
Yeah that is a good summary.
The reason we don't use histograms heavily in the server is because of the
memory issues. We originally did use histograms for everything, then we ran
into all
From: Jay Kreps [jay.kr...@gmail.com]
Sent: Thursday, March 26, 2015 2:29 PM
To: dev@kafka.apache.org
Subject: Re: Metrics package discussion
Yeah that is a good summary.
The reason we don't use histograms heavily in the server is because of the
memory issues. We
have a
couple more opinions.
Thanks,
Aditya
From: Jay Kreps [jay.kr...@gmail.com]
Sent: Thursday, March 26, 2015 2:29 PM
To: dev@kafka.apache.org
Subject: Re: Metrics package discussion
Yeah that is a good summary.
The reason we don't
this for metrics we can quota on may not be a bad place to start.
Thanks,
Aditya
From: Jay Kreps [jay.kr...@gmail.com]
Sent: Wednesday, March 25, 2015 11:08 PM
To: dev@kafka.apache.org
Subject: Re: Metrics package discussion
Here was my understanding of the issue last
[jay.kr...@gmail.com]
Sent: Wednesday, March 25, 2015 11:08 PM
To: dev@kafka.apache.org
Subject: Re: Metrics package discussion
Here was my understanding of the issue last time.
The yammer metrics use a random sample of requests to estimate the
histogram. This allocates a fairly large array
Here was my understanding of the issue last time.
The yammer metrics use a random sample of requests to estimate the
histogram. This allocates a fairly large array of longs (their values are
longs rather than floats). A reasonable sample might be 8k entries which
would give about 64KB per
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
18 matches
Mail list logo
