mirror of
https://github.com/wezm/wezm.net.git
synced 2024-12-19 02:39:54 +00:00
Finished version of speed-up-slow-ios-downloads-with-proxy
This commit is contained in:
parent
a47416a31c
commit
54beee02de
1 changed files with 46 additions and 48 deletions
|
@ -1,12 +1,13 @@
|
||||||
---
|
---
|
||||||
title: Speed Up Slow Downloads on iOS with a Proxy or CDN
|
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
|
kind: article
|
||||||
section: technical
|
section: technical
|
||||||
created_at: 2013-01-13 12:39:00
|
created_at: 2013-01-13 12:39:00
|
||||||
keywords:
|
keywords:
|
||||||
- ios
|
- ios
|
||||||
- proxy
|
- proxy
|
||||||
|
- slow
|
||||||
- download
|
- download
|
||||||
- podcast
|
- podcast
|
||||||
- squid
|
- squid
|
||||||
|
@ -14,71 +15,63 @@ keywords:
|
||||||
- cdn
|
- cdn
|
||||||
---
|
---
|
||||||
|
|
||||||
Whilst developing the Radiopaedia iOS app I ran into the problem of very slow
|
Whilst developing the [Radiopaedia iOS app][radiopaedia-app] I ran
|
||||||
download speeds within the app. The app has packs of content avaiable for
|
into the problem of very slow download speeds within the app. The app
|
||||||
purchase. The download speed was fine in the simulator but on the device it
|
has packs of content available for purchase and download. The download
|
||||||
was painfully slow. Profiling the code didn't reveal any issues either.
|
speed was fine in the simulator but on the device it was painfully
|
||||||
|
slow<sup>1</sup>. 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
|
[radiopaedia-app]: http://radiopaedia.org/articles/radiopaedia-ios-radiology-app
|
||||||
faster over 3G than Wi-Fi. There were a number of theories and proposed fixes
|
|
||||||
for this including:
|
|
||||||
|
|
||||||
* YouTube was sending higher bitrate video when on Wi-Fi
|
Some searching revealed people complaining about YouTube videos
|
||||||
* Checking Wi-Fi access point settings
|
downloading faster over 3G than Wi-Fi. There were a number of theories
|
||||||
* Set access point to 802.11b and it goes faster
|
and proposed fixes, including [people seeing faster rates when
|
||||||
|
downgrading their access point to 802.11b][80211b]<sup>2</sup> 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 AU<sup>3</sup>.
|
||||||
|
|
||||||
At the time I read something that I can no longer find that said that the
|
[80211b]: http://web.archive.org/web/20120511020134/http://qelix.com/blog/2008/08/31/get-better-wifi-speeds-on-iphone-3g
|
||||||
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.
|
|
||||||
|
|
||||||
With this in mind I tested hosting the content packs on an Australian server,
|
With this in mind I tested hosting the content packs on an Australian
|
||||||
instead of in Amazon S3. This showed a huge improvement in download speed. At
|
server, instead of in Amazon S3 accessed via CloudFront. This showed a huge
|
||||||
the time Amazon's CloudFront CDN did not have an Australian presence so we
|
improvement in download speed. At the time CloudFront didn't
|
||||||
switched to hosting the packs on RackSpace's CloudFiles, which uses the much
|
have an Australian presence so we switched to hosting the packs on
|
||||||
more extensive Akamai CDN and ensured that users of the app would have the
|
RackSpace's CloudFiles, which uses the much more extensive Akamai CDN
|
||||||
best possible download speeds.
|
and ensured that users of the app would have the best possible download
|
||||||
|
speeds no matter where they were.
|
||||||
|
|
||||||
<div class="seperator"><hr class="left">✦<hr class="right"></div>
|
<div class="seperator"><hr class="left">✦<hr class="right"></div>
|
||||||
|
|
||||||
Fast forward a year or so and I started managing podcasts on my phone instead of
|
Fast forward a year or so and I started managing podcasts on my phone
|
||||||
via iTunes. I noticed that some of the podcasts I was subscribed to were horrendously
|
instead of via iTunes. I noticed that some of the podcasts I was
|
||||||
slow to download. A 100Mb file would take many hours to download, particularly
|
subscribed to were horrendously slow to download. Some would take hours
|
||||||
ones hosted a long way away, such as in the UK or
|
to download, particularly ones hosted a long way away, such as in the
|
||||||
The Netherlands. I also noted that podcasts that used a CDN downloaded quickly.
|
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.
|
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
|
I wondered if telling the iPhone to use a proxy on the local
|
||||||
network would work around the issue. since effectivly move
|
network would work around the issue.
|
||||||
the destination onto the local network as far as the phone
|
|
||||||
is concerned (since it will just be talking to the proxy).
|
|
||||||
|
|
||||||
So I set up [Squid][squid] on the Mac mini that's connected to my TV
|
To test my theory I set up [Squid][squid]<sup>4</sup> on the Mac
|
||||||
(using [Homebrew][homebrew])
|
mini that's connected to my TV since it's always on and has a wired
|
||||||
since it's always on and has a wired connection to my modem.
|
connection to my modem. I configured the iPhone to use the proxy and
|
||||||
I configured the iPhone to use the proxy an lo-and-behold the
|
compared the speed with, and without the proxy in use.
|
||||||
very same podcast downloads that were taking hours, now took
|
|
||||||
minutes.
|
|
||||||
|
|
||||||
[squid]: http://www.squid-cache.org/
|
[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
|
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
|
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
|
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
|
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
|
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
|
[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
|
||||||
<figcaption>Podcast download with proxy, 491 kb/sec</figcaption>
|
<figcaption>Podcast download with proxy, 491 kb/sec</figcaption>
|
||||||
</figure>
|
</figure>
|
||||||
|
|
||||||
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:
|
launchd to start squid on boot:
|
||||||
|
|
||||||
<script src="https://gist.github.com/4521952.js"></script>
|
<script src="https://gist.github.com/4521952.js"></script>
|
||||||
|
|
||||||
|
----
|
||||||
|
|
||||||
|
<sup>1</sup> Tested on iPhone 3GS and iPhone 4S.
|
||||||
|
<sup>2</sup> Original article linked from [Apple support discussion](https://discussions.apple.com/message/9564410#9564410).
|
||||||
|
<sup>3</sup> It appears there's YouTube end-points in AU these days.
|
||||||
|
<sup>4</sup> I installed squid using [Homebrew](http://mxcl.github.com/homebrew/).
|
||||||
|
|
Loading…
Reference in a new issue