[alexkus]

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.

[nehz]

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 :)