Speakers: Dan Burcaw & Joe Pezzillo (Push IO) – former Apple employees
Their current application infrastructure supports iOS, Android, Windows Phone 7 (and some other that they can’t discuss)
Admitted Real time data… is their focus. Might bias their info.
SOAP is out! Payload is just way to bloated.
REST is in (with JSON) -lightweight
Parser Speed Iphone 3Gs: Built in iOS xml parser takes 2 seconds! Even best is just under a second.. That’s a long time on a mobile device.
Many of the fastest engines also have feature tradeoffs… just don’t have a ton of great options when looking at a XML parser from a performance perspective.
JSON performance is way faster: A few tested: Touch JSON, JSON Framework, YAJL, ApplJSON … Worse case of writing < 0.5 second.. Reading <0.1 sec
JSONKit is blazing fast. This is a new one to look at.
JSON benefits:
- Compact data format (even more compact if whitespace is stripped)
- Very fast read/write speeds compared to XML
- JSON Libraries make it easy to convert from dict key/values into native objects
- JSON is well-supported on the server-side
TIP: Use JSONLint.com to view and ensure JSON is formated correctly.
Backend scalability/performance:
Data requests: Mobile is much more async. A different kind of load that can bring down server from traditional web based traffic. To coordinate the data your WebService is providing, You likely need to use one or more databases.
Might be best to make a ton of smaller calls, instead of ‘a large data set’ all at once. Don’t frontload the data load as that doesn’t scale well.
Probably best to increase the number of calls your app makes, by making lots of calls for small amounts of data, only data that you need at that point.
Databases: Consider using in-memory databases such as Redis or Memcached to eliminate request/response bottlenecks. Traditional disk-based dbs don’t scale well when serving medium to large scale mobile apps do to the volume of async requests.
Tip: Use in memory databases on the front end, then write to disk db periodically. They use a ‘LAMP stack’ (these are called noSQL db’s)
Couch DB, mongoDB, Redis or Memcached are most popular NoSQL db’s now.
TIP: Web server settings: be sure to turn on GZIP compression. This HTTP Header setting will reduce the size of the data payload sent across the wire.
Mobile data files: not all data needed by mobile apps need a full fledged SOAP/REST WS:
Consider publishing static (vs dynamic) JSON files to a CDN, which avoids taxing your servers with dynamic requests.
This is really saying.. Determine data that is static.. and make that something different to call… instead of dynamic seek on all data requests.
CDN pricing is ‘very cheap’ if you aren’t dealing with Video. ( < fewer than $50 over a number of months)
TIP: When working with CDN’s, set your time to live very low.
Static file could be written out every second (more like 30 seconds). That’s static in the mobile world (expand your mind here)… could certainly do this thing on a min by min basis. This really offloads traffic to the CDN instead of the Caching benefits of a CDN.
Server virtualization has some limits: Performance in particular. MySQL performance suffers on a virtualized server. Switched to ‘Bare Metal’ MySQL. Even that wasn’t performing as well… this is why they went to the in memory (noSQL) DB’s. This is a probably when you exceed a ‘reasonable number of users’ think 10,000 users type thing.
Mobile apps… people don’t linger like on the web… lots of requests instead of just one on mobile. (check it, check it, check it… lots of little data requests)
Registration/personalization doesn’t map well to the Mobile data files technique. (Writes of data need to be handled differently than the consuming of data on the handheld.)
Realtime tips:
- REST-full WebServices with JSON Responses
- Gzip compression
- Mobile data files via CDN (low cache control policies)
- In-memory databases
- Load balancers and multiple worker nodes.
Theme = ”Do as little as possible in realtime” for highly scalable solutions.
Overall, I received many tips to consider. Opened up my mind to many new possibilities to consider for the systems I currently work with and felt I gained a large amount of background info to consider as we grow our user base. I am most interested in seeing what we might be able to do with a NoSQL DB. This may be a great first step for us.