What's up with read concurrency

[stijn-nefkens]

We noticed a strong decline in performance when upgrading 3.6.2 to 3.8.6 (python 3.9). It turned out that we could no longer have multiple open requests in parallel (tcp). How come this feature was removed? The information I could find was an old thread (#475) that indicates it shouldn't exist and a reference to locks in patch 3.6.9.

[janiversen]

Multiple requests have not been supported for quite a while.

The client API have not permitted it cleanly since something like 3.1. Since something like 3.3 there have been a low level lock in place to secure against competing requests.

Only a handful of devices support multiple requests, and even for those the requests are still executed one by one, and execution is typically a factor slower than the tcp socket communication, so even with those devices you save next to nothing.

When testing we have not seen a real decline in performance on the contrary performance have improved quite a lot.

May I suggest you do not upgrade if you do not like the newer versions.

Btw. 3.8 is anyhow a very old version, we are at 3.11

[stijn-nefkens]

Sorry I forgot to mention that this is from a server perspective (StartAsyncTcpServer). The test was performed using a client (Bachmann) connected that supports concurrent reads and the server from 3.6.2 was over 10x faster as it was serving the requests in parallel (e.g. request | request | request | response | response | response). Wireshark logs showed the 3.8.6 server was serially serving requests (e.g. request | response | request | response | request | response). I'll try to repeat the test with version 3.11.

[janiversen]

Interesting, especially because the server was never capable of serving requests in parallel, the current implementation is basically the old sync version with a async transport.

The server handles requests from multiple clients in parallel.

Your wireshark analysis merely shows that the client do not send the next request until it gets a response....it does not show how the server handles the requests.

However I am quite confused, are you saying the server or the client is slow ?

The pattern of the server have not changed since 3.2, but the client have. Earlier you could trix the client into sending multiple requests, but with a fair chance that it would not work as expected, which is why never versions are more strict. Please remember the client API is strictly request/response based...so if you do multiple client.read_holding_register() without the await, you are asking for trouble.

I have no idea how you calculate the 10x faster, considering the server is serializing the requests, so all you do in parallel is the transfer of the requests.

[stijn-nefkens]

We were using two versions of the pymodbus server (3.6.2 and 3.8.6) and a single external client (not pymodbus). So no change in client, just a change in the version of the modbus server (pymodbus). Queries are run at 250 ms interval.

3.6.2

3.8.6

[janiversen]

I hear what you are saying, but let's get one thing clear: the client decides when to send requests, the server merely responds to these, so when you see multiple requests being sent without a response, it means the server cannot keep up and queues the requests.

On the other hand when you see requests are responded to before next request is sent, means one of 2 things:

• the server is keeping up and do not queue
• the client wait for the response before sending next request.

Please look at the time between the response and the next request, it is huge and have nothing whatsoever to do with the server.

There are clearly a change in how your client works, I cannot tell you why....but if you remove the lost time between a response and the next request, the second example is actually faster.

[janiversen]

Just controlled the server have basically not changed between 3.6.2 and 3.8 especially not in terms of transport. 3.8 and 3.9 have quite a number of server changes in more or less all layers.