[
https://issues.apache.org/jira/browse/KAFKA-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15107827#comment-15107827
]
Jay Kreps commented on KAFKA-3115:
----------------------------------
[~ijuma] It showed up as a heavy hitter in hprof profiling when we did the
producer originally and I was reminded of it when we were looking at small
message performance for the 0.9 release. hprof isn't terribly accurate, and I'm
not 100% sure if the impact is to the app thread or the i/o thread. I was just
filing this since I remembered that and thought I should put it somewhere out
of my head. This only impacts throughput for smaller messages I suspect.
> Remove locking in metrics package
> ---------------------------------
>
> Key: KAFKA-3115
> URL: https://issues.apache.org/jira/browse/KAFKA-3115
> Project: Kafka
> Issue Type: Improvement
> Reporter: Jay Kreps
>
> Currently there is synchronization inside the call
> Sensor.record(value)
> This one lock covers updating all the metrics associated with the Sensor.
> The nice thing about this is that it makes the implementation of the various
> stats very simple since they can always assume they execute inside a lock.
> Unfortunately the metrics show up as one of the biggest perf hits in the
> producer when sending small messages.
> It might be possible to optimize this. One approach would be to try to make
> the stats themselves threadsafe. Obviously introducing locking in the stats
> themselves would make things worse than they currently are (since the problem
> is the overhead of the lock not the contention). However it might be possible
> to cut-and-paste the code for DoubleAdder or AtomicDouble (neither are
> included in java 7) and do some tricky coding.
> The hard bits would be SampledStat and Histogram.
> Prior to attempting this, it would make sense to remove the synchronization
> and benchmark the producer to see how much improvement is actually possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
