How can I measure the breakdown of network time spent in iOS?

Question

Uploads from my app are too slow, and I'd like to gather some real data as to where the time is being spent.

By way of example, here are a few stages a request goes through:

1. Initial radio connection (significant source of latency in EDGE)
2. DNS lookup (if not cached)
3. SSL/TLS handshake.
4. HTTP request upload, including data.
5. Server processing time.
6. HTTP response download.

I can address most of these (e.g. by powering up the radio earlier via a dummy request, establishing a dummy HTTP 1.1 connection, etc.), but I'd like to know which ones are actually contributing to network slowness, on actual devices, with my actual data, using actual cell towers.

If I were using WiFi, I could track a bunch of these with Wireshark and some synchronized clocks, but I need cellular data.

Is there any good way to get this detailed breakdown, short of having to (gak!) use very low level socket functions to reproduce my vanilla http request?

Answer 1

An easy solution to this would be once the application get's fired, make a Long Polling connection with the server (you can choose when this connection need's to establish prior hand, and when to disconnect), but that is a kind of a hack if you want to avoid all the sniffing of packets with less api exposure iOS provides.

Answer 2

Ok, the method I would use is not easy, but it does work. Maybe you're already tried this, but bear with me.

I get a time-stamped log of the sending time of each message, the time each message is received, and the time it is acted upon. If this involves multiple processes or threads, I have each one generate a log, and then merge them into a common timeline.

Then I plot out the timeline. (A tool would be nice, but I did it by hand.) What I look for is things like 1) messages re-transmitted due to timeouts, 2) delays between the time a message is received and the time it's acted upon.

Usually, this identifies problems that I can fix in the code I can control. This improves things, but then I do it all over again, because chances are pretty good that I missed something the last time.

The result was that a system of asynchronous message-passing can be made to run quite fast, once preventable sources of delay have been eliminated.

There is a tendency in posting questions about performance to look for magic fixes to improve the situation. But, the real magic fix is to refine your diagnostic technique so it tells you what to fix, because it will be different from anyone else's.