Hi all,
Currently the bottleneck happens at getPendingOperations API. That method
takes a while to be executed as it involves both fetching the next
operations & updating the status of completed operations. The complete
getPendingOperations flow has more than 5 database calls (as I remember)
Hi All,
I think going forward, we need a queue to be present, for communications
going both ways. As Charitha highlighted, when multiple devices are
targeted, we need to be able to define a dynamic distribution strategy that
will gradually ramp up the rate of distribution, depending on success
Can we get all device requests through a message broker and let the broker
handle spikes? Then the broker has to be scalable.. however, it anyway has
to be scalable as devices can publish monitoring events to the broker
(which can occur frequently by a large number of devices).
Regards,
Chathura
Hi Geeth,
IMO, all the current information retrieval and monitoring operations could
run in parallel from device to device.
In that case, cannot we maintain a task pool at server side where we would
allocate some defined set of operations to each task and dynamically expand
the pool based on
Hi,
IMO we can send a timeout with the operation which, once the operation/
notification is received by the device, it waits for the given timeout and
respond back to the server to perform the operation. All operations are
sent to devices at ones and the timeout should be different to each
Hi All,
I think it is better to have a solution which could be implemented in
server side to distribute operations among devices. Because as we know
device agents in IoTS devices are different to each other. In according to
our architecture, we are letting anyone to write their own device types
Hi all,
We have encountered an issue with balancing load distribution of device +
server communication. Device and server communication happens through
following ways.
1. Polling - Device keeps polling the server
2. Push notification - Server sends a notification to device to come
