0

We need to develop a high speed REST based WCF Service , which will be used for updating 2000 datapoint , each data point changing at 25 msec . Is it possible to implement such high speed data acquisition using WCF

Sabarish Sathasivan
  • 1,196
  • 2
  • 19
  • 42
  • This question needs some clarification. Are you saying that you're making 2000 updates inside the service, and the cost of each update is 25 milliseconds? If that is the case then the overhead of your communication protocol will not be significant. Please be specific: where is the 25 ms delay encountered? Is concurrency a problem? How are you defining high speed (i.e. what are your specific performance constraints) – Paul Keister Sep 07 '13 at 22:29
  • Sorry for being ambigious. The following is the scenario . we have multiple devices from which we need to acquire data. Each device will have up to 2000 data points. Each data point value can change at 25 msec. we need to record all the value changes.... Hope i am more clear – Sabarish Sathasivan Sep 08 '13 at 04:27

2 Answers2

0

Using WCF yes. I'm not sure REST is the best architectural style for the type of problem you are trying to solve. I also wonder whether HTTP is appropriate.

Having said that you might want to look into CORE which is an effort to apply REST in highly constrained environments like data acquisition.

Darrel Miller
  • 139,164
  • 32
  • 194
  • 243
0

Here is how I am understanding your question: you expect new data values every 25 ms, or 40 x per second. There are 2000 discrete data values is one device, which means the telemetry flow from each device is around 80,000 values per second. You also have multiple devices, so your throughput will go higher than this, e.g. 800,000 updates per second for 10 devices.

In this scenario, I wouldn't expect the service layer to be a constraint, for the simple reason that it is always possible to scale up the service layer by adding more hosts to receive messages and load balancing between them. Where I would be concerned is any place where all transactions must be processed within the same domain. For example, is all this data winding up in one relational database? In that case you may have a problem with transaction throughput.

Another area that seems problematic in your architecture is the device itself. Is one device going to be capable of gathering and sending out values at 80 kHz? Here is where the REST protocol may have have too high an overhead. So it is device, not server, constraint that might drive you to find a more efficient protocol. This may be a case where writing a custom protocol directly against the socket might be warranted, but that depends on your device.

Paul Keister
  • 12,851
  • 5
  • 46
  • 75
  • Thanks Paul for your guidance – Sabarish Sathasivan Sep 09 '13 at 15:52
  • Could you let us give us more information on how to scale up the service layer by adding more hosts to receive messages and load balancing between them – Sabarish Sathasivan Sep 09 '13 at 18:05
  • I'm afraid this topic is too broad for a stackoverflow question. However, if you don't have the technical expertise to set up a load balanced server farm, one easy and economical way to achieve this architectur is by deploying your service Windows Azure cloud service - load balancing is build to the Azure clouds service platform. – Paul Keister Sep 11 '13 at 04:16