I am trying to find the optimal solution for sending a large number of small messages (usually about 1000 per second, maybe up to 10000 per second. Each message is up to 1 KB), via the Internet, but with the lowest possible latency (for example, about financial data). I started with the basic Duplex WCF channel - it was perfect for the local network. Then I needed to change my contract so that it was turned on (the OperationContractAttribute property with IsOneWay set to true), because otherwise each message was waiting for confirmation, and therefore the network latency was counted twice for each message. Even after this, my service still sometimes doesn’t catch up (and on the server side I just read the messages from the queue and immediately send it, on the client side I just issue a message after receiving it and do not block it).
I am wondering if there is any overhead caused by sending a large number of small messages. Is there a better way (e.g. streaming over TCP)?
Edit1: Based on the reviews, I add a little technical information:
Our service is in Singleton instance mode, which can be called at the same time ([ServiceBehavior (InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple)].)
We did not configure throttling, so it has default values (however, there are very few simultaneous clients - from 1 to 4)
In fact, we use a duplex channel - client calls to (registers), and then the server sends a large number of messages to the client. The client itself performs very few calls. The server calls the client through the reverse channel Channel in a synchronized manner (we iterate through the blocking queue), but very, very often (the mentioned ~ 1000 messages per second, but even several thousand per second).
Edit2: Explanation why this is not a duplicate for How well does WCF scale for a large number of client clients? question:
In our scenario, we actually have very few clients (even if only one client is considered), but a large number of messages are constantly sent to this client - so this looks like a streaming script.
We have already taken measurements of a typical client scenario and service throughput and found that at present we cannot scale well in some situations (for an over-the-Internet client at short intervals of the day, when more messages are sent, then they are, probably queued by WCF, as we temporarily see an increase in delay in reception time).
Scaling to several server mailboxes, unfortunately, is not a viable solution for us (one client needs to connect to one server all day).