ProduceAsync too slow
See original GitHub issueDescription
I’m working on a software to consume a stream from a Socket.IO source and putting into Kafka.
The messages are about 100bytes each and I receive about 20000 messages per second from Socket.IO.
For each message I call ProduceAsync().Result
but this method slows down to 1 message per second.
Why is this happening? How can I resolve?
Other observations
- I need a strict order of the messages so I cannot remove the
.Result
and use the async method. - I’ve checked the time span of both the serialize and deserialize functions (I use custom functions) and both are above 50ms
- Till some hours ago I was working with RC2 and the bug was still the same, I’ve updated the version hoping it was fixed
- The stream source (the one from Socket.IO) works like a charm if I don’t produce it into kafka
- I’ve found many other users experiencing a very similar problem with the consumer #619, #573 , #554
- @mhowlett here states that “maximum sustainable consume throughput is about 150k msg/s for 100 byte messages” I hope for the producer is about the same
- I’ve found other users with the same problem in #501 , #495, #471
Checklist
Please provide the following information:
- Confluent.Kafka nuget version: 1.0.0-BETA
- Apache Kafka version: 2.11
- Client configuration:
SocketBlockingMaxMs = 1
- Operating system: both Windows and Docker Linux
- Provide logs (with “debug” : “…” as necessary in configuration)
- Provide broker log excerpts
- Critical issue
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:14 (8 by maintainers)
Top Results From Across the Web
Kafka producer is slow on first message
I think I tried tuning all producer configs, nothing helps except setting EnableDeliveryReports = false. · Topic is not partitioned and already ...
Read more >Kafka .NET Client
As such, await``ing the ``ProduceAsync call will result in very low throughput except in highly concurrent applications such as an ASP.NET request handlers....
Read more >Kafka Producer - C# Sync vs Async - Concurrent Flows
Essentially, Produce() is "Producing" faster than we're "Delivering". The big highlight is that -. Both Produce() and ProduceAsync() are ...
Read more >confluent-kafka-dotnet
When using ProduceAsync , any delivery result other than NoError will cause the returned Task to be in the faulted state, with the...
Read more >Performant .NET producer example | CDP Private Cloud
Review this example code to learn how you can create a more complex, high-performing .NET producer with async processing and TPL. This producer...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Synchronous produce will be slow, effectively limited by the broker round-trip and processing time.
You might want to try out the new idempotent producer support which adds in-order guarantee. Enable with
enable.idempotence=true
on the producer.Do note that this feature is still in beta state.
Clearly that’s expensive! That’s what we were doing wrong. We just need to keep the publisher alive and reuse it for each call.
Thanks for the help!
Sean Buchanan
From: Matt Howlett notifications@github.com Sent: Friday, October 5, 2018 2:21:44 PM To: confluentinc/confluent-kafka-dotnet Cc: sean-buchanan; Mention Subject: Re: [confluentinc/confluent-kafka-dotnet] ProduceAsync too slow (#630)
the only 1s delay I see there is after you shut down the producer. are you creating a new producer for every produce call? that’s extremely expensive.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/confluentinc/confluent-kafka-dotnet/issues/630#issuecomment-427487681, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AUFmzJECAOss9ddm3Qff4eSxxZCMKxV8ks5uh79YgaJpZM4W5LA8.