0

Based on Google's App Engine cost structure where CPU is more costly than bandwidth, is it beneficial to enable gzip compression to your iOS app? Has anyone enabled gzip and seen the real-word cost savings (or cost increase!)?

Background: Our app will primarily serve text content to iOS. iOS supports gzip compression, but it must be turned on in the client by passing the accept-encoding and user-agent headers per: https://developers.google.com/appengine/kb/general#compression

However if gzipped content is sent, iOS will automagically decode it: NSURLConnection/NSURLRequest gzip support

Since we write our iOS app, it's up to us whether to use compression or not. In my past life, the significant bandwidth savings vs. minor CPU usage increase were easily worthwhile. Looking at the CPU vs. Bandwidth costs in GAE, it's not so clear. It could actually cost us money to enable compression.

So has anyone experimented with their iOS app and seen if gzip support saves money? Our app isn't live yet, so I can only do very fudgy cost comparisons in dev, which unfortunately make compression appear to cost MORE money.

Community
  • 1
  • 1
Squirrel7
  • 11
  • 2
  • This probably varies for each app. You'll need to do your own testing to see for sure. The only comment I can offer is that most text is *highly* compressible, so if most data is text, it may be worth it anyway. Finally, if you do the gzipping yourself instead of leaving it to a framework, you'll be able to control the speed-vs-compression ratio -- which will let you choose a slightly worse compression ratio in exchange for faster (read: less CPU usage) encoding. – Cameron Apr 04 '12 at 15:32
  • I would have thought that for a mobile app on a cellular network bandwidth savings are always good to have – Frederick Cheung Apr 04 '12 at 15:32
  • "CPU is more costly than bandwidth" how on earth would you measure that? – Nick Johnson Apr 05 '12 at 05:20
  • @NickJohnson Looking at GAE pricing and the amount of CPU vs. bandwidth we're using in our dev environment, even if gzip added 1% CPU and got 50% compression, we would be paying extra to compress instead of saving money. – Squirrel7 Apr 10 '12 at 15:20
  • @Squirrel7 Compression doesn't cost proportional to how much CPU the rest of your app consumes, though - so comparing it on a percentage basis is meaningless. – Nick Johnson Apr 11 '12 at 01:05

2 Answers2

2

If a client sends the correct Accept-Encoding header, and a recognized User-Agent, the App Engine infrastructure will compress content for you, without involvement from your app. Gzipping HTTP responses is almost always a good idea, unless you're sending naturally uncompressible data.

Nick Johnson
  • 98,961
  • 16
  • 125
  • 196
  • Any idea if GAE users pay for the compression in CPU time, since it isn't being done within the app? I'm used to compression being a no-brainer, but with the CPU cost on GAE I'm not so sure. – Squirrel7 Apr 10 '12 at 15:22
  • @Squirrel7 No, you're not charged for compression or decompression. Under the new billing model, CPU time isn't charged for anyway. – Nick Johnson Apr 11 '12 at 01:04
  • Sorry if I'm being dense, but as long as the instance is doing the compression, and you (potentially) need more instances to handle the increased CPU usage, doesn't that amount to being charged for compression/decompression CPU time? Thanks for the responses Nick, I'm trying to convince my team we should be using compression but it's an uphill battle. – Squirrel7 Apr 11 '12 at 18:01
  • @Squirrel7 The instance doesn't do the compression, the frontend does. And I'm astonished that your team would even need to debate this - quite apart from anything else, compression makes your webapps faster and more responsive by decreasing user-perceived latency. – Nick Johnson Apr 11 '12 at 23:42
1

It's worth it to decrease to load time on your app more than anything else. Even on a high speed wifi connection the latency in your app is from downloading data. Uncompressing is very fast.

Rick Mangi
  • 3,681
  • 1
  • 11
  • 16