Scaling Secret: Real-Time Chat
medium.com
medium.com
We also used Pusher for global in-app notifications, which had to scale past 1,000,000 concurrent connections.
Aside: 50000 concurrent requests on a single thread, huh? :) Unless I'm missing something, that's 50 seconds assuming a request takes only 1ms to process. Sounds like magic.
https://www.techempower.com/benchmarks/#section=data-r10&hw=...
1ms to route a chat message is plenty.
e.g. on a single AWS m1.small prosody[1] can process 40,000 stanzas per second.
It's not as if there is a shortage of available tech for handling socket connections. It took about a week for me to learn enough node.js and build a service with socket.io that did everything I needed.
Depends on your application. Generally, if you have 1,000,000 concurrent users, shouldn't you be making some money or have investment to tide you over?
My app has ~3000 concurrent users, which comes out to 250,000 users per day making in the order of $XX,XXX per month.
At 1,000,000 concurrent, we'd expect to have 83 million users per day visiting the site. At that rate, we'd be making at the very least hundreds of thousands of dollars per month and could easily afford a $39,000/mo chat service.
$399/month is a tiny drop in that bucket. It is almost certainly not a good use of engineering resources for Secret to build their own in-house Pusher alternative, even if it would only take a single engineer a few days.
We're currently working with a couple of fast growing startups so it's getting traction (still early adopter stage though). We'll be announcing our native iOS client near the end of this week. (disclosure: I'm the main author)
Are there any true peer to peer chat apps left, or do they all go through some server now, even after call setup?
I wonder if there's a good way to do this now, as some plug in somewhere... Even XMPP's file forwarding functionality fails for me.
Bittorrent recently released 'Bleep' which supports encrypted peer-to-peer chat including image transfer. It holds the message locally until a direct connection to the receiver is established.
The gist of your argument is that Pusher is "nothing more than a cash grab for lazy developers," which insults not just the creators of the service but also people who use it.
Just because DIY alternatives exist for something does not mean that thing should not be used, or that people who use it are "lazy."
I personally find it ridiculous to pay for a service like Pusher, when I know that I can accomplish the same goals with FOSS without much extra effort. For the record, I feel the same way about Heroku, so take my opinion for what its worth... I don't intend to hide my bias.
I believe people should understand and take responsibility for their systems (when possible) instead of just defaulting to relying on proprietary, closed services and software.
Will Pusher still be supported in 5 years? Will it still be affordable? Will it remain stable? Will the number of connections I'm allowed on my current plan stay the same? These are questions I don't have to ask.
I admit my assertion that Pusher is "...nothing more than a cash grab..." is a little hyperbolic, and I mean no disrespect to the people who created and maintain it, but in some way it is true. Pusher is a business that relies on its users not having the time or know how to implement the service it provides on their own.
Max 20 connections... Want 21? pay $20/month...
I can copy and paste the example chat from socket.io and push it to a VPS and instantly do way better for much less.
By that rationale, pretty much every business on the planet that provides a service is nothing more than a cynical cash grab. Maybe you need to grow up a bit.
I respect Pusher and what they do to make money. There is a market, and Pusher is there to fulfill its needs. I cannot take issue with that. All I'm saying is that there are better options.
Anyways, I see a lot of tearing apart specific things I say, but not a lot of reasons why relying on Pusher is a better option than rolling your own... I welcome that sort of discussion.
For now, its time for bed.
Couldn't be more impressed with them. Keep it up!
I've never implemented this, which I think is the reason I am underestimating the service that Pusher provides. It would be great if someone that did implement it would convince me that it would be a large hassle to do that internally.
With a go server on a GCE n1-standard-2 you should be able to handle over 100k connections per server. I haven't done any benchmarks for throughput, but using redis as the messaging backend you can do pretty well.
You take 100k connections on each of the endpoint servers and make a single redis connection, using redis pubsub to subscribe to channels. Publishers can connect to the same redis and publish to those channels.
If you wanted bi-directional it could work a similar way I think, I'd guess the specific architecture depends on your requirements.
A scalable cluster of Socket.IO servers isn't.
Also patting my own back for thinking about chat session based on sorted user id's (for 2+ person chat) on my own once also. Felt like a nice way to do it, unsure if that breaks down at any point.
There's to be a lot of hate on here towards using such services. Is it really a better option (flexibility, owning your data & price wise) to spend the time building your own system and having to hire engineers later on to manage/develop it?
The bits we are preparing for the main service are quite large (architecturally) but we hope to be beta testing them soon.
edit: source: http://caniuse.com/#search=webrtc