4 ms·
The 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 is
by smokinn 18y ago
The 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.