31, 2018 at 8:35 AM, David Espinosa wrote:
> I used:
> -Djute.maxbuffer=50111000
> and the gain I had is that I could increment number of topics from 70k to
> 100k :P
>
> 2018-01-30 23:25 GMT+01:00 Andrey Falko :
>
>> On Tue, Jan 30, 2018 at 1:38 PM, David Espinosa wrote:
&
ger the topic names
> are the sooner jute.maxbuffer overflows.
I see; what value(s) have you tried with and how much gain did you you see?
> David
>
>
> 2018-01-30 4:40 GMT+01:00 Andrey Falko :
>
>> On Sun, Jan 28, 2018 at 8:45 AM, David Espinosa wrote:
>> > Hi Mont
On Sun, Jan 28, 2018 at 8:45 AM, David Espinosa wrote:
> Hi Monty,
>
> I'm also planning to use a big amount of topics in Kafka, so recently I
> made a test within a 3 nodes kafka cluster where I created 100k topics with
> one partition. Sent 1M messages in total.
Are your topic partitions replic
fore it
falls over and/or starts failing to meet various SLAs we've made with
our users. I'll try to "correct" the original mistake that I made,
however, I hope that an operator error like mine doesn't take out a
production cluster this like this :).
Best regards,
Andrey Falko
Salesforce.com
e info to share soon.
On Wed, Jan 3, 2018 at 4:47 PM, Jun Rao wrote:
> Hi, Andrey,
>
> If the test is in the normal mode, it would be useful to figure out why ZK
> is the bottleneck since the normal mode typically doesn't require ZK
> accesses.
>
> Thanks,
>
> Jun
&
de, we are now discussing KIP-227, which could reduce the
> overhead for replication and consumption when there are many partitions.
>
> Jun
>
> On Wed, Jan 3, 2018 at 1:48 PM, Andrey Falko wrote:
>
>> Hi everyone,
>>
>> We are seeing more and more push fro
rk to have kafka support more than that?
Best regards,
Andrey Falko
Salesforce.com
