[ 
https://issues.apache.org/jira/browse/KAFKA-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14587281#comment-14587281
 ] 

Jun Rao commented on KAFKA-2102:
--------------------------------

[~timbrooks], thanks for the patch. Took a quick look at it. The change does 
seem to add some more complexity.

A producer client typically either optimizes for (1) latency or for (2) 
throughput.

For (1), the volume of the data is relatively low. So I am not sure if there 
will be lots of lock contention in this case. Could you run the test with just 
1 thread and see if there is any improvement in latency? Also, the saving of a 
few micro-secs is going to be negligible in the end-to-end latency with real 
network involved.

For (2), typically, people will enable compression. In this case, maybe the 
compression overhead will dominate? Could you run some tests with compression 
enabled?



1. Your performance result showed improved latency in the order of a few 
micro-second. However, most people probably can more about end-e. However, 
frthe a few us improvem

> Remove unnecessary synchronization when managing metadata
> ---------------------------------------------------------
>
>                 Key: KAFKA-2102
>                 URL: https://issues.apache.org/jira/browse/KAFKA-2102
>             Project: Kafka
>          Issue Type: Improvement
>            Reporter: Tim Brooks
>            Assignee: Tim Brooks
>         Attachments: KAFKA-2102.patch, KAFKA-2102_2015-04-08_00:20:33.patch, 
> KAFKA-2102_2015-04-15_19:55:45.patch, KAFKA-2102_2015-04-26_17:25:21.patch, 
> eight-threads-patch.txt, eight-threads-trunk.txt, five-threads-patch.txt, 
> five-threads-trunk.txt
>
>
> Usage of the org.apache.kafka.clients.Metadata class is synchronized. It 
> seems like the current functionality could be maintained without 
> synchronizing the whole class.
> I have been working on improving this by moving to finer grained locks and 
> using atomic operations. My initial benchmarking of the producer is that this 
> will improve latency (using HDRHistogram) on submitting messages.
> I have produced an initial patch. I do not necessarily believe this is 
> complete. And I want to definitely produce some more benchmarks. However, I 
> wanted to get early feedback because this change could be deceptively tricky.
> I am interested in knowing if this is:
> 1. Something that is of interest to the maintainers/community.
> 2. Along the right track
> 3. If there are any gotchas that make my current approach naive.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to