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 # user >> Analysis of producer performance


+
Piotr Kozikowski 2013-04-08, 23:43
+
Jun Rao 2013-04-09, 04:49
+
Guy Doulberg 2013-04-09, 06:34
+
Piotr Kozikowski 2013-04-09, 17:23
+
Otis Gospodnetic 2013-04-10, 19:05
+
Piotr Kozikowski 2013-04-10, 20:11
+
Yiu Wing TSANG 2013-04-11, 02:47
+
Jun Rao 2013-04-11, 05:18
+
Piotr Kozikowski 2013-04-12, 00:46
+
Jun Rao 2013-04-12, 14:54
+
Piotr Kozikowski 2013-04-12, 23:09
Copy link to this message
-
Re: Analysis of producer performance
Piotr,

Not sure where the updated numbers are. but what you described may make
sense. In the no ack mode, if the broker is saturated, it will put back
pressure to the producer. Eventually, the producer will slow down because
the socket buffer is full. One big difference btw 0.8 and 0.7 is that the
0.8 broker has the overhead of recompressing compressed messages. If you
only have one partition in your test, all producers have to synchronize on
the log when doing recompressing, which could limit the throughput. To
improve the throughput, you can try using more partitions, turning off
compression or using a cheaper compression codec like snappy.

Thanks,

Jun
On Fri, Apr 12, 2013 at 4:08 PM, Piotr Kozikowski <[EMAIL PROTECTED]>wrote:

> Hi all,
>
> I posted an update on the post (
> https://blog.liveramp.com/2013/04/08/kafka-0-8-producer-performance-2/) to
> test the effect of disabling ack messages from brokers. It appears this
> only makes a big difference (~2x improvement ) when using synthetic log
> messages, but only a modest 12% improvement when using real production
> messages. This is using GZIP compression. The way I interpret this is that
> just turning acks off is not enough to mimic the 0.7 behavior because GZIP
> consumes significant CPU time and since the brokers now need to decompress
> data, there is a hit on throughput even without acks. Does this sound
> reasonable?
>
> Thanks,
>
> Piotr
>
> On Mon, Apr 8, 2013 at 4:42 PM, Piotr Kozikowski <[EMAIL PROTECTED]>
> wrote:
>
> > Hi,
> >
> > At LiveRamp we are considering replacing Scribe with Kafka, and as a
> first
> > step we run some tests to evaluate producer performance. You can find our
> > preliminary results here:
> > https://blog.liveramp.com/2013/04/08/kafka-0-8-producer-performance-2/.
> > We hope this will be useful for some folks, and If anyone has comments or
> > suggestions about what to do differently to obtain better results your
> > feedback will be very welcome.
> >
> > Thanks,
> >
> > Piotr
> >
>

 
+
Philip OToole 2013-04-12, 15:22
+
S Ahmed 2013-04-12, 15:28
+
Philip OToole 2013-04-12, 15:59
+
Philip OToole 2013-04-12, 17:04
+
Piotr Kozikowski 2013-04-15, 18:19
+
David Arthur 2013-04-23, 12:22
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