~10ms latency on publishing and receiving message on the same machine on windows about emqx HOT 6 CLOSED

I tried the same thing using node-red and the same latency is observed

Can you elaborate on this part? Do you observe ~10ms latency with node-red as well? If so, it could be a problem with the test setup, e.g. client side buffering.

from emqx.

client side buffering.

listeners.tcp.my_tcp_listener_name {
    bind = 1883 
    tcp_options {
        nodelay = true
    }
}

I added this to my configuration file to attempt to disable nagle's algorithm, but It doesnt seem to change anything , is there a way to test that ?

from emqx.

My question was: do you observe the same end-to-end latency with both EMQX and node-red? If so, it could be a problem with the load generator (e.g. paho client does buffering on its own, or there is some GIL issue with python).
This can be easily ruled out by inspecting a wireshark trace.
In my tests (1 pub -> 1 sub using emqtt client on Linux), the average round-trip latency is ~0.5 ms.
Also, if you use Rule Engine with some heavy rules the latency can increase.

from emqx.

do you observe the same end-to-end latency with both EMQX and node-red?

yes using both the python script and node-red , I observe same ~10ms latency , the broker is on the same machine

wire shark trace using python script

wireshark trace using node-red

In my tests (1 pub -> 1 sub using emqtt client on Linux), the average round-trip latency is ~0.5 ms.

hmm can you confirm latency stays the same at a high frequency , like sending a small packet every 100ms

from emqx.

hmm can you confirm latency stays the same at a high frequency , like sending a small packet every 100ms

I used the following script ./emqttb --pushgw @pub --pubinterval 100ms -N 1 --metadata -t foo/%n @sub -N 1 --parse-metadata -t foo/# (emqttb is a wrapper for emqtt that turns it into a scriptable loadgen) which essentially emulates your setup. Results look like this:

Another reason for increased latency could be a large number of inactive clients that subscribe to the topics without any traffic. This can make routing table lookups slower.

from emqx.

I close this ticket, because:

• We highlighted some causes for the increased latency.
• In the original test the packets go through the LAN (192.168.1.100), it adds network latency that we cannot control
• My attempts to reproduce the problem in a more controlled environment (packets are routed through lo) weren't successful
• Windows build is intended for local prototyping only, we don't tune it for high throughput/low latency whatsoever.

from emqx.