Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Kafka >> mail # dev >> [jira] [Comment Edited] (KAFKA-736) Add an option to the 0.8 producer to mimic 0.7 producer behavior


Copy link to this message
-
[jira] [Comment Edited] (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:comment-tabpanel&focusedCommentId=13569840#comment-13569840 ]

Neha Narkhede edited comment on KAFKA-736 at 2/3/13 6:37 PM:
-------------------------------------------------------------

In all the tests above, the number of partitions is 1. I think to compare the 2 patches, we don't need to worry about changing the # of partitions simply because there is no change in the Log layer in both patches. But, just for curiosity, I can give that a try. Here are the results -

Number of producer threads 20
Number of partitions 10
Batch size 100
Message size 1K

v3 patch

2013-02-03 18:34:59:834, 2013-02-03 18:35:01:327, 0, 1000, 100, 95.37, 61.8764, 100000, 66979.2364

draft patch

2013-02-03 18:34:05:757, 2013-02-03 18:34:07:132, 0, 1000, 100, 95.37, 70.3581, 100000, 72727.2727

Still a ~13 % performance degradation
                
      was (Author: nehanarkhede):
    In all the tests above, the number of partitions is 1. I think to compare the 2 patches, we don't need to worry about changing the # of partitions simply because there is no change in the Log layer in both patches. But, just for curiosity, I can give that a try.
                  
> 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

 
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB