When considering network performance, response time is a key metric that developers and ops teams monitor.  One challenge with lowering response time is determining which network component is adding latency; is it the server, the ISP, the operating system, or the speed of light?  At Apteligent, we recently ran experiments to determine what portion of network response time is added by mobile operating systems.  For mobile devices, it turns out that if your web service responds slower than 200ms, the O/S adds much more time than you may have thought.

To set up an experiment, we forked a repo of httpbin, which is a simple web server whose response times can be controlled based on URL paths.  For example, an HTTP GET to http://httpbin.org/delay/3 would result in a response time of 3 seconds.  We made a small modification to the code to change the units to milliseconds.  Next, we ran 10 trials with response times ranging between 0 to 1000 milliseconds at increments of 25 milliseconds.  Finally, we used the Apteligent SDK’s service monitoring capability to collect response times for each of the network requests.

The output of the experiment is a table with two columns: known server response time and measured response time as seen in the app.  We ran the experiment on our office wifi network, where the added response time is close to nil (based on ping times between laptops). Subtracting these numbers gives us the response time contributed by the operating system (and potentially any in-between APIs).

We ran the experiment on an iPhone 5 and an Android Galaxy Nexus.  Just for fun, we upgraded the iPhone from 6.1.2 to 7.0.3 and ran the experiment again.

An interesting sawtooth pattern emerged from all of the data.  It is not completely clear what is causing this, but perhaps it is some type of I/O scheduler or interrupt handler that performs work on a periodic basis.

Interestingly, Apple and Android (or maybe BSD and Linux?) have chosen slightly different approaches for scheduling I/O.  Apple’s algorithm is a bit less favorable for very fast response times, but it is less volatile for longer response times.  Android on the other hand adds almost zero additional response time so long as the service responds in less than 200ms.  After 200ms, Android adds another 200ms.  Ouch!

So what does this mean for developers and ops teams?  Well, it appears that mobile operating systems smooth out response times.  Your server could return in 300ms, but the OS will add another 300 giving a “real” response time of 600ms.  On the other hand, your server could return in 600ms and the OS will only add 30ms, giving a “real” response time of 630ms.  On the contrary, bringing your servers response times down from 300ms to 200ms might pay bigger dividends.

At the end of the day, gaming the client’s I/O scheduler is an unlikely way to improve performance.  Just know that your server isn’t the only thing holding your app back from warp speed performance.

Happy hacking!