kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Kreps (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-736) Add an option to the 0.8 producer to mimic 0.7 producer behavior
Date Mon, 04 Feb 2013 20:16:12 GMT

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

Jay Kreps commented on KAFKA-736:

This makes sense, nice catch.

I think to make an informed decision we really need to also test the acks>0 case with,
say, 20 threads. The reason is because the assumption is that the multi-queue design will
have better throughput but worse latency. If multi-queue has equally good latency then I think
the decision is very easy. If latency is worse then I suppose it depends how much worse? Producer
perf test measures latency too, right?
> 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

View raw message