3 ms·
The author seems to confuse push with polling: > Consider an application with just 10,000 users. It might service a million uses per day, assuming update check
by mcav 18y ago
The author seems to confuse push with polling:
> Consider an application with just 10,000 users. It might service a million uses per day, assuming update checks every 15 minutes. More time-critical uses might demand checks every few minutes or even several times a minute. As the computational burden builds, so do the hosting costs. While cloud computing provides an excellent match to these kinds of needs, that kind of solution comes with a real price in development, maintenance, and day-to-day operations.
With push, small developers are saved from the hassle of handling lots of polling connections. They just push according to what their application needs -- it's more scalable, and that's the point.
- wmf 18y agoIt depends. Consider the prototypical iPhone app, the Twitter client. AFAIK, the Twitter API only supports polling, but the iPhone only supports push for background notifications. Thus the app developer is left to build (and pay for) a polling/pushing adaptor. Somebody like Gnip could make good money here.
- tesseract 18y agoOr consider an instant messaging client - incoming messages are pushed from the IM service, but not directly to the iPhone in the format it understands, so the app developer would have to operate a server that maintains an open connection to the IM server for each app user and forwards incoming messages to their iPhones.
- collint 18y agoIt really is a good thing that multiple pieces of software exsists for doing just such a thing. Modern messaging middleware can handle in the range of hundreds of thousands of messages per second. Talent and domain knowledge will be important, but iPhone "push" changes little.
- smokinn 18y agoThe real problem with push is that you have to deal with a massive number of open connections. Most web servers just aren't designed to handle that. Polling isn't much of a problem with proper caching. Push is for cases where data is truly time critical. If it's no big deal for the data to get there a few seconds after it's been generated polling every 10 seconds will usually cause less strain on your servers than keeping lots of connections open. Just don't hit the database every 10 seconds! Generate your data before the request, throw it up in memcached and pick it out of memory when the request comes along.
- sokoloff 18y agoSo in your proposed solution, you're going to "push" the data to memcached, but rely on polling to get the data to the end user, right? If the problem is that your webserver doesn't handle large numbers of open quiescent connections well, then don't use that webserver. Clearly you're capable of writing the application that is pushing the data into memcached. Just have that same (type of) app push the data to the end consumer. Designing a naturally push app to be push-into-cache and then poll seems to be going the long way around. It may also set you up for a terrible scaling "elbow" where at some point with increasing load, you'll suddenly be polling for data that was just expired from memcached and you may have little warning that that's about to happen. Apple's worries about battery life and end-user experience are valid and no amount of tears from small developers is going to change them. They have to keep giving the consumer a good experience, which is ultimately what you/we as developers have to do. If that changes the economics slightly, so be it, but Apple is rightly concerned foremost about the buyers of iPhones, not the developers for them.