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 demand. It's more of a divide-and-concur approach that I am suggesting here.
Thanks, Dilan. *Dilan U. Ariyaratne* Senior Software Engineer WSO2 Inc. <http://wso2.com/> Mobile: +94766405580 <%2B94766405580> lean . enterprise . middleware On Mon, Feb 27, 2017 at 11:09 PM, Geeth Munasinghe <ge...@wso2.com> wrote: > 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 > retrieve the operation. (wake up call) > 3. Push message - Whole message is pushed to device as notification. > > In 1 and 2 ways, device always comes to server to pick up the operation. > (In MDM scenarios, we use only 1 and 2) We have found few scenarios where > this would lead to a request overload to the server. > > 1. Device information retrieval > 2. Device application list retrieval > 3. Device location retrieval > 4. Policy monitoring > 5. Installing/Uninstalling application (Role based) > > First four scenarios are handled by background tasks. These tasks are > responsible for adding an operation against each of the device. This > process would notify the device regarding operation or device will come to > server at a pre-configured time to retrieve the operation. Specially with > the notification process, when an operation is added to all the device, > notification is send to all of them. In iOS, we send to the notification to > APNS, for android - GCM/FCM and for Windows - WNS. These notification > services normally deliver the messages to devices quickly. Therefore as > soon as device receives the notification, it starts to contact the server. > If this happens with a server which has 1,000s of devices enrolled, most of > devices start retrieving the operation from the server which leads to a > request a burst. 5th scenario happens when we install an application to a > role which has 1,000s of users. This also starts sending notifications to > all the devices of those users, which would result in a request burst. > > As a solution, we can limit the number of devices notified at given > moment. Only set of devices will receive the notification at first, then > after some time interval second set of devices will receive the > notification and continue until all the devices are notified. This way, we > can make sure only chunk of devices receives the notification, hence reduce > the server load. > > Please give your feedbacks and suggestions. > > Thanks > Geeth > > -- > > *G. K. S. Munasinghe* > *Senior Software Engineer,* > *WSO2, Inc. http://wso2.com <http://wso2.com/> * > *lean.enterprise.middleware.* > > email: ge...@wso2.com > phone:(+94) 777911226 <+94%2077%20791%201226> > > <http://wso2.com/signature> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
