[
https://issues.apache.org/jira/browse/KAFKA-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15107802#comment-15107802
]
Ismael Juma commented on KAFKA-3115:
------------------------------------
As you said, one should remove the synchronization and quantify the possible
improvement. Given that this is not the only lock we use in the producer, what
is the reasoning for thinking that this one is particularly problematic
(contention was already ruled out in the description)? Is it because it gets
invoked more often than other ones, is held for longer, something else?
> 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)
