[
https://issues.apache.org/jira/browse/KAFKA-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569828#comment-13569828
]
Jun Rao commented on KAFKA-736:
-------------------------------
Thanks for the results. The case with 20 producer threads is pretty
interesting. How many partitions are there in the topic? If there is only 1
partition, all I/O threads will need to synchronize on the same log during
append. So, this will serialize all I/O threads and therefore the reading of
the next produce request. If this is the case, I'd suggest that we try with
more partitions in the topic, with sth like 20 network threads.
> Add an option to the 0.8 producer to mimic 0.7 producer behavior
> ----------------------------------------------------------------
>
> Key: KAFKA-736
> URL: https://issues.apache.org/jira/browse/KAFKA-736
> Project: Kafka
> Issue Type: Improvement
> Components: producer
> Affects Versions: 0.8
> Reporter: Neha Narkhede
> Assignee: Neha Narkhede
> Priority: Blocker
> Labels: p2, replication-performance
> Attachments: check-message-ordering.py, kafka-736-draft.patch,
> kafka-736-v1.patch, kafka-736-v2.patch, kafka-736-v3.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I profiled a producer throughput benchmark between a producer and a remote
> broker. It turns out that the background send threads spends ~97% of its time
> waiting to read the acknowledgement from the broker.
> I propose we change the current behavior of request.required.acks=0 to mean
> no acknowledgement from the broker. This will mimic the 0.7 producer behavior
> and will enable tuning the producer for very high throughput.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
