From 54beee02de44c50e3c0a3f90dd3e7f0e416bf595 Mon Sep 17 00:00:00 2001 From: Wesley Moore Date: Sun, 13 Jan 2013 16:10:13 +1100 Subject: [PATCH] Finished version of speed-up-slow-ios-downloads-with-proxy --- ...peed-up-slow-ios-downloads-with-proxy.html | 94 +++++++++---------- 1 file changed, 46 insertions(+), 48 deletions(-) diff --git a/content/technical/2013/01/speed-up-slow-ios-downloads-with-proxy.html b/content/technical/2013/01/speed-up-slow-ios-downloads-with-proxy.html index d7c4871..12cb814 100644 --- a/content/technical/2013/01/speed-up-slow-ios-downloads-with-proxy.html +++ b/content/technical/2013/01/speed-up-slow-ios-downloads-with-proxy.html @@ -1,12 +1,13 @@ --- title: Speed Up Slow Downloads on iOS with a Proxy or CDN -extra: How to speed up downloads on iOS. +extra: Using a proxy or CDN can dramatically improve download speeds on an iOS device. kind: article section: technical created_at: 2013-01-13 12:39:00 keywords: - ios - proxy +- slow - download - podcast - squid @@ -14,71 +15,63 @@ keywords: - cdn --- -Whilst developing the Radiopaedia iOS app I ran into the problem of very slow -download speeds within the app. The app has packs of content avaiable for -purchase. The download speed was fine in the simulator but on the device it -was painfully slow. Profiling the code didn't reveal any issues either. +Whilst developing the [Radiopaedia iOS app][radiopaedia-app] I ran +into the problem of very slow download speeds within the app. The app +has packs of content available for purchase and download. The download +speed was fine in the simulator but on the device it was painfully +slow1. Both the Mac running the simulator and device were +connected to the same Wi-Fi network. Profiling the code didn't reveal +any issues either. -Some searching revealed people compaining about YouTube videos downloading -faster over 3G than Wi-Fi. There were a number of theories and proposed fixes -for this including: +[radiopaedia-app]: http://radiopaedia.org/articles/radiopaedia-ios-radiology-app - * YouTube was sending higher bitrate video when on Wi-Fi - * Checking Wi-Fi access point settings - * Set access point to 802.11b and it goes faster +Some searching revealed people complaining about YouTube videos +downloading faster over 3G than Wi-Fi. There were a number of theories +and proposed fixes, including [people seeing faster rates when +downgrading their access point to 802.11b][80211b]2 but I +found one particular article (that I can no longer find) that said the +power management in the iOS Wi-Fi stack interfered with download speeds +when communicating to a high latency destination over a high speed Wi-Fi +connection. For example YouTube servers in the US from AU3. -At the time I read something that I can no longer find that said that the -iOS Wi-Fi stack has problems when it has a low latency Wi-Fi -connection that is communicating to a comparatively high latency -destination, for example YouTube servers in the US from AU (it -appears there's YouTube end-points in AU these days). From memory I think the -article cited power management under these circumstance as the issue. Howver -since I can't find the original article I might be making that up. +[80211b]: http://web.archive.org/web/20120511020134/http://qelix.com/blog/2008/08/31/get-better-wifi-speeds-on-iphone-3g -With this in mind I tested hosting the content packs on an Australian server, -instead of in Amazon S3. This showed a huge improvement in download speed. At -the time Amazon's CloudFront CDN did not have an Australian presence so we -switched to hosting the packs on RackSpace's CloudFiles, which uses the much -more extensive Akamai CDN and ensured that users of the app would have the -best possible download speeds. +With this in mind I tested hosting the content packs on an Australian +server, instead of in Amazon S3 accessed via CloudFront. This showed a huge +improvement in download speed. At the time CloudFront didn't +have an Australian presence so we switched to hosting the packs on +RackSpace's CloudFiles, which uses the much more extensive Akamai CDN +and ensured that users of the app would have the best possible download +speeds no matter where they were.
✦
-Fast forward a year or so and I started managing podcasts on my phone instead of -via iTunes. I noticed that some of the podcasts I was subscribed to were horrendously -slow to download. A 100Mb file would take many hours to download, particularly -ones hosted a long way away, such as in the UK or -The Netherlands. I also noted that podcasts that used a CDN downloaded quickly. +Fast forward a year or so and I started managing podcasts on my phone +instead of via iTunes. I noticed that some of the podcasts I was +subscribed to were horrendously slow to download. Some would take hours +to download, particularly ones hosted a long way away, such as in the +UK or The Netherlands. I also noted that podcasts that used a CDN +downloaded quickly. This seemed to be the same problem I had encountered with the Radiopaedia app. I wondered if telling the iPhone to use a proxy on the local -network would work around the issue. since effectivly move -the destination onto the local network as far as the phone -is concerned (since it will just be talking to the proxy). +network would work around the issue. -So I set up [Squid][squid] on the Mac mini that's connected to my TV -(using [Homebrew][homebrew]) -since it's always on and has a wired connection to my modem. -I configured the iPhone to use the proxy an lo-and-behold the -very same podcast downloads that were taking hours, now took -minutes. +To test my theory I set up [Squid][squid]4 on the Mac +mini that's connected to my TV since it's always on and has a wired +connection to my modem. I configured the iPhone to use the proxy and +compared the speed with, and without the proxy in use. [squid]: http://www.squid-cache.org/ -[homebrew]: http://mxcl.github.com/homebrew/ - -To be sure I paused the download, changed the phone's settings -to not use the proxy and restart the download, give it a few -minutes and the estimate was hours. - * Turn the proxy back on and minutes. You can see this in action in the screenshots below. The first is not using the proxy. I have let it download a third of the file to be well -clear [TCP's slow start][slow-start] and it is estimating 57 minutes to +clear of [TCP's slow start][slow-start] and it is estimating 57 minutes to download the remaining 176.1 Mb (53 kb/sec). The second screenshot (only -a minutes later) shows the result after I paused the download, changed +a minute later) shows the result after I paused the download, changed the proxy settings and then again let the download warm up a little. The estimated time to complete the remaining 143.8 Mb is now only 5 mins -(491 kb/sec) -- a huge improvment. +(491 kb/sec) -- a huge improvement. [slow-start]: https://en.wikipedia.org/wiki/Slow-start @@ -92,9 +85,14 @@ estimated time to complete the remaining 143.8 Mb is now only 5 mins
Podcast download with proxy, 491 kb/sec
-After the successful experiement I left the phone using the proxy and configured +After the successful experiment I left the phone using the proxy and configured launchd to start squid on boot: +---- +1 Tested on iPhone 3GS and iPhone 4S. +2 Original article linked from [Apple support discussion](https://discussions.apple.com/message/9564410#9564410). +3 It appears there's YouTube end-points in AU these days. +4 I installed squid using [Homebrew](http://mxcl.github.com/homebrew/).