Interesting. We're using APE for something similar (can't go into too much detail as it'll spoil our stealth mode) but with different scaling requirements.
We have messages that need to go to our users in three tiers of channels:-
a) a bunch of "control" messages to all users (~200 a day to n users)
b) users can form subgroups (from 1 to n users) each "control" message will likely require a unique push for each subgroup
c) individual pushes to each user
Right now (b) and (c) aren't being performed using APE, we just make the clients poll for the new data once they receive a "control" message, but it's better to push the data out to the individual users rather than have them bother a webserver to get the info - even if it is just being served from memcached or varnish and never bothering the backend DB.
APE is good for us right now, but with ideas for supporting a much greater number of users (>100,000) I'm planning on knocking up a replacement in C. APE is just overkill for our needs. I'll probably also end up having to use libnetfilter-queue to process the raw TCP directly as kernel memory buffers (4KB each for read/write buffers for each connection) soon add up with >1M users but if it gets that far it'll be a lovely problem to have.
Yes.. having a large amount of concurrent users (>100,000) is definitely a challenge, and polling each time adds to the load as you are creating a new connection every time.
Our approach was based on horizontal scaling of commodity hardware (on Amazon EC2). We have X number of worker instances serving clients and they internally publish and subscribe using a Redis cluster. Have a look into Redis, ZeroMQ or RabbitMQ.
But definitely give our service a try in your free time or for your side projects :)
Thanks for your comment. We believe offering our users more choice is always a good thing. Moreover, while we do provide a similar service, the way we deliver and our goals are slightly different.
Pusher uses WebSockets; this is awesome and a very forward thinking technology however can be limited by older browsers and proxies not supporting the WebSocket connection. Notifyr uses EventSource (also a HTML5 spec) and XMLHttpRequest, aiming to support a majority of browsers, including mobile browsers.
Additionally, we aim to integrate with Apple and Google's push notification system in the future, allowing a universal method for sending push messages with one API for any platform, device or browser.
macspoofing|13 years ago
• http://www.buddy.com/ • http://js.dotcloud.com/ • https://cloudmine.me/ • http://backlift.github.com/docs/ • http://www.meteor.com/main • https://parse.com/about/index • http://derbyjs.com/ • http://www.kinvey.com/ • http://www.stackmob.com/ • http://www.appcelerator.com/cloud • http://pusher.com/ • http://www.firebase.com/ • http://www.pubnub.com/ • https://www.getbridge.com/ • https://www.tambur.io/
alexkus|13 years ago
We have messages that need to go to our users in three tiers of channels:-
a) a bunch of "control" messages to all users (~200 a day to n users) b) users can form subgroups (from 1 to n users) each "control" message will likely require a unique push for each subgroup c) individual pushes to each user
Right now (b) and (c) aren't being performed using APE, we just make the clients poll for the new data once they receive a "control" message, but it's better to push the data out to the individual users rather than have them bother a webserver to get the info - even if it is just being served from memcached or varnish and never bothering the backend DB.
APE is good for us right now, but with ideas for supporting a much greater number of users (>100,000) I'm planning on knocking up a replacement in C. APE is just overkill for our needs. I'll probably also end up having to use libnetfilter-queue to process the raw TCP directly as kernel memory buffers (4KB each for read/write buffers for each connection) soon add up with >1M users but if it gets that far it'll be a lovely problem to have.
nehz|13 years ago
Our approach was based on horizontal scaling of commodity hardware (on Amazon EC2). We have X number of worker instances serving clients and they internally publish and subscribe using a Redis cluster. Have a look into Redis, ZeroMQ or RabbitMQ.
But definitely give our service a try in your free time or for your side projects :)
StavrosK|13 years ago
nehz|13 years ago
Pusher uses WebSockets; this is awesome and a very forward thinking technology however can be limited by older browsers and proxies not supporting the WebSocket connection. Notifyr uses EventSource (also a HTML5 spec) and XMLHttpRequest, aiming to support a majority of browsers, including mobile browsers.
Additionally, we aim to integrate with Apple and Google's push notification system in the future, allowing a universal method for sending push messages with one API for any platform, device or browser.
macspoofing|13 years ago
nehz|13 years ago
knes|13 years ago
[deleted]