-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maximum message / s throughput for a single subscriber can't stay above 10000 m/s #1962
Comments
I increased some of EMQX's broker settings to allow up to 10,000 inflight messages at any given time and I increased the queue size to 1m messages per MQTT topic. Still seeing things top out around 10k msg/s even after adjusting that. |
Can you profile your client side where the most time in the code is spent? |
Hi @Aaronontheweb, |
Great advice - thank you |
@bajinder so this did not help me - pumped the receive buffer up from the default of 8kb to 1mb. Still petered out around the same point. Tried doing some work using the |
Verification
Using version 4.3.3.952 in Release mode on .NET 8 with logging disabled.
Describe the bug
I'm currently running a small PoC using Akka.NET and MQTTnet via an EMQX broker using the following settings:
And the following event handler - which just writes to an unbounded
ChannelWriter<T>
:I'm seeing MQTTnet fail to keep up with my workload starting around 10,000 msg/s - and gradually it will fail as the queue gets too large on EMQX (the broker will automatically disconnect the client.)
Even if I change my
ManagedMqttClient_ApplicationMessageReceivedAsync
to just return aTask.CompletedTask
and not do any actual processing, I still see this issue: MQTTnet can't keep up with the rate of messages coming from the broker.For the project I'm working on each subscriber in an MQTT subscriber group will need to be able to process ~30,000 msg/s - is that possible with this library?
Which component is your bug related to?
Tried with both the
Client
and theManagedClient
but it didn't seem to make any difference.Expected behavior
I'd expect MQTTnet to keep up beyond 10k msg/s.
Additional context / logging
These are some of the logs from EMQX - it just gives up on the client because the input queue gets too long:
This ends up creating a snowballing effect where the client is never really able to keep up.
The text was updated successfully, but these errors were encountered: