You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Neha Narkhede (JIRA)" <ji...@apache.org> on 2013/02/02 02:53:11 UTC
[jira] [Updated] (KAFKA-736) Add an option to the 0.8 producer to
mimic 0.7 producer behavior
[ https://issues.apache.org/jira/browse/KAFKA-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Neha Narkhede updated KAFKA-736:
--------------------------------
Attachment: check-message-ordering.py
We have the producer performance that can take in an option to produce messages with an id per thread and a configurable number of threads. We can then run console consumer and the script attached here to see if messages are ordered per thread. Please cross check this script, I'm a Python noob!
./bin/kafka-producer-perf-test.sh --broker-list localhost:9092 --initial-message-id 1 --messages 100000 --threads 10 --topics sequential
bin/kafka-run-class.sh kafka.consumer.ConsoleConsumer --zookeeper localhost:2181 --topic sequential --consumer-timeout-ms 10000 --from-beginning > sequential-output &
python -B check-message-ordering.py -f sequential-output
Output from script -
Checking ordering for thread 1
All 20000 messages are ordered
Checking ordering for thread 0
All 21000 messages are ordered
So far, using this test I couldn't reproduce the reordering problem on the draft patch, but I ran a short test.
> 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
>
> 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