Optimizing Worklight apps and server for use in slow (EDGE/GPRS/2G) networks
SrihariKulkarni 120000KKWK Visits (5392)
Despite many advances in wireless network technologies, access to high speed mobile networks is not all pervasive especially in growth markets such as India, Africa and South East Asia. In these markets, the most popular way to access the Internet is through GSM, GPRS or EDGE. These networks have various data transfer rates which are in the order of upto a few hundred kbits per second. In this document, we will refer to such networks as Slow networks.
The aim of this document is to provide a comprehensive set of guidelines and recommendations to optimize user experience on slow networks with respect to
a. Writing applications designed to be used on slow networks
b. Configuring IBM Worklight
c. Configuring other products commonly used in conjunction with IBM Worklight such as Application servers, proxy & reverse-proxy servers etc.
Writing IBM Worklight apps with slow networks in mind
When Worklight applications are run on mobile devices that access the server over a slow network, it is important to reduce the amount of data transfer between the device and the server to ensure faster interaction with the user. Even when the amount of data transfer is minimized, it is equally important to keep the user apprised of the estimated time to complete an operation over the network. The following recommendations can be used while building IBM Worklight applications to ensure the aforementioned conditions are satisfied.
Starting IBM Worklight 6.0, it is possible for IBM Worklight applications to request data in a compressed format in response to invokeProcedure calls. Since data returned by the IBM Worklight server is in JSON format, compressing adapter responses greatly reduces the amount of data transferred and therefore the time taken to complete a response.
The following code snippet demonstrates how to request for a compressed response from the server in case of a Hybrid application.
During laboratory tests, it was found that compression adapter responses improves the response time by upto 73% especially for large payloads on slow networks. The following chart shows typical response times with compression turned on and off for various sizes of payload*.
As you can notice from the chart, for data sizes of 500 kilobytes and above, the gap widens and compressing the payload pays good dividends. In addition to reducing the response time, data charges are reduced too.
Each invokeProcedure call made by the device is subject to a default timeout of 30 seconds. If your invokeProcedure call expects a large amount of data from the adapter over a slow network, consider increasing the timeout.
The above snippet of code demonstrates how to increase the adapter timeout from the default of 30 seconds to 60 seconds.
The following chart shows typical response times for various payloads*
As you can see from the chart, for payloads of size of approximately 250 KB and above, the data transfer time exceeds the default timeout interval. This necessitates that applications expecting data in this range should adjust the adapter response timeout appropriately.
Another factor influencing invokeProcedure timeout on the device is the actual time taken by the adapter to respond. If your adapter takes a significant amount of time to fetch data from the backend, then this must be factored in the timeout value you set during invokeProcedure. In general, ensure
(invokeProcedure timeout) >= (Adapter response time) + (Transmission time over the network)
Despite the best measures taken, slow networks, by their very nature are unpredictable with respect to speed and reliability. It is therefore recommended that application desginers be cognizant of this fact and build resilience to such timeouts within their applications. For example, applications can retry an timed out operation with a larger timeout value. A typical JSON response from the Worklight server when a timeout occurs is given below. This can be accessed in the onFailure callback
IBM Worklight Application Center provides a mobile client which can be used to download and update applications. Delivering application updates through the Application Center provides the devices with capabilities such as resumable downloads and automatic retry of broken downloads. These features are especially recommended for devices that install and update applications over slow networks.
Starting Worklight 6.1, a failed direct update is automatically resumed from the point of failure in the Worklight app. However, in earlier versions of Worklight, successful direct updates of applications over slow networks depends on sustained reliability of the mobile network over a large period of time while the update is being downloaded. Frequent loss of signal, network congestion can lead to disrupted and hence failed direct updates.
It is therefore advised to keep the application footprint as small as possible to minimize chances of direct update failure. IBM Worklight sends a compressed version of the update file to the client to minimize data charges as well as to increase chances of a successful direct update over slow networks. Should direct updates fail frequently over slow networks, the end user must be advised to continue the direct update when a better network, such as WiFi is available.
A failure during Direct Update as a result of network troubles will present the user with an error message as shown below
This blog post brings in a summary of best practices that can be used by developers and administrators of IBM Worklight to optimize Worklight apps to work best on slow networks (GSM/EDGE/GPRS). Is there anything that you think can be done to improve app performance over a slow network ? Feel free to comment.
* Note : The data presented here are experimental values obtained for random JSON data and may change based on various external factors such as network congestion, signal strength and other factors influencing network delays