4

I'm trying to find an optimal solution for sending large amount of small messages (usually around 1000 per sec, can be up to 10000 per sec. Each message is up to 1KB large), over the internet, but with minimal possible latency (think e.g. about financial data). I started with basic Duplex WCF channel - that was great for local network. Than I needed to change my contract to be oneway (OperationContractAttribute with IsOneWay property set to true), as otherwise each message waited for confirmation and so 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'm just reading messages from the queue and immediately sending, on the client side I just enqueue message after receiving and do not block).

I'm wondering if there is some overhead caused by sending large number of small messages. Is there a better way (e.g. some sort of streaming over TCP)?

Edit1: Based on feedback I'm adding little technical info:

Our service is in Singleton instance mode that can be called concurrently ([ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple)]).

We didn't configure throttling so it has default values (however there is just very few concurrent clients - 1 to 4)

In fact we use duplex channel - client calls in (registers) and then server is sending large amount of messages to client. Client itself performs very little calls. Server calls the client via callback Channel in synchronized way (we iterate through blocking queue), however very, very frequently (those mentioned ~1000 messages per sec, but even few thousands per sec).

Edit2: Explaining why this is not a duplicate to How well will WCF scale to a large number of client users? question:

In our scenario we actually have very small number of clients (let's even consider just one single client), but large number of messages being continuously sent to that one client - so it's something like streaming scenario.

We already did the measurements of typical client scenario and service throughput and found that we currently cannot scale well in some situations (for over-the-internet client at the short times in day when there is larger number of messages needed to be sent - then those are probably queued by WCF as we temporarily see increasing delay in receiving time).

Scaling out to multiple server boxes isn't unfortunately viable solution for us (one client need to be connect to one server for whole day).

Community
  • 1
  • 1
Jan
  • 1,905
  • 17
  • 41
  • @Mgetz In our scenario we actually have very small number of clients (let's even consider just one single client), but large number of messages being continuously sent to that one client - so it's something like streaming scenario. And scaling out to multiple server boxes isn't unfortunately viable solution for us (one client need to be connect to one server for whole day). – Jan Jul 18 '13 at 15:09
  • 1
    You may need to drop WCF and write your own protocol. Abstractions like WCF are great to make things easier to write, but every layer of abstraction adds a layer of work, which adds a layer of delay. – Scott Chamberlain Jul 18 '13 at 15:41

1 Answers1

0

How did you configured the serviceThrottling ? (see MSDN serviceThrottling) Also please provide the InstanceContextMode configuration of your service.

sundog
  • 179
  • 6
  • I've added the info to my question. – Jan Jul 18 '13 at 16:30
  • 1
    Web Service streaming could be a solution for you, as sending lots of small messages per second is similar to sending large amount of data. To separate messages you coud just stream a specific byte as separator. In my project we use streaming for services that return large amounts of data (over 10 Gb). Please see [link](http://msdn.microsoft.com/en-us/library/ms733742.aspx) on how to configure streaming on WCF services. Hope it helps – sundog Jul 19 '13 at 13:54