Do you have anything like this up on github?
Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
11–20 of 41 posts
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#12Earlier quoted context omitted.
but has this design been implemented to effectively handle something close to a million users Obviously not. Some of his numbers are off by an order of magnitude. E.g. he claims "10 million messages/sec" for a single redis instance. In reality redis tops out at well under one million messages/sec; http://redis.io/topics/benchmarks The design is almost comically bad (single source of truth for a "scalable" chat app?!)…
Oh, you're absolutely right, 10M/s is a mistake, which I've corrected. Few remarks though: - it's still way below the number of actions we're talking about here (~100k/s) - since redis is only used as a generic MQ and not as a store, it can be sharded at the app level without the pain usually associated with redis clustering - I've deployed a similar (but less performant) design for the player of a gaming website, wh…
Feedback?
How about just not making wild claims about byzantine fantasy designs that you never tested under any kind of load.
There has been a lot of research in messaging architectures, some of the best message brokers are free. As it happens, none of them have any resemblance to your proposed design.
RabbitMQ has been benchmarked[1] to 1 million messages/sec on 30 servers and works very well for many people.
Why not start with that?
[1] http://blog.pivotal.io/pivotal/products/rabbitmq-hits-one-mi...
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#13Do you have anything like this up on github?
The author has a bunch of "nexus-*" repos for this idea. Don't know if they actually work for "millions of users". It will only be adopted when it's battle tested anyway.
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#14Earlier quoted context omitted.
Oh, you're absolutely right, 10M/s is a mistake, which I've corrected. Few remarks though: - it's still way below the number of actions we're talking about here (~100k/s) - since redis is only used as a generic MQ and not as a store, it can be sharded at the app level without the pain usually associated with redis clustering - I've deployed a similar (but less performant) design for the player of a gaming website, wh…
Feedback? How about just not making wild claims about byzantine fantasy designs that you never tested under any kind of load. There has been a lot of research in messaging architectures, some of the best message brokers are free. As it happens, none of them have any resemblance to your proposed design. RabbitMQ has been benchmarked[1] to 1 million messages/sec on 30 servers and works very well for many people. Why no…
This benchmark is indeed very interesting.
I think I may have failed to express my point, though. I'm not building a message queue, as it is certainly a very hard problem that has been engineered for years by people way smarter than me :) I'm merely leveraging the goodness of their implementations (in my case redis, but RabbitMQ is also an option I've considered explicitly in my post).
The chat is a contrived example to show that even under high load, full-scale flux over the wire is a reasonable option. As for "any kind of serious load", well, maybe my example fails to meet the requirements, but unless I'm building Facebook, I think I've faced something serious enough to be able to think about my next step.
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#15Earlier quoted context omitted.
Feedback? How about just not making wild claims about byzantine fantasy designs that you never tested under any kind of load. There has been a lot of research in messaging architectures, some of the best message brokers are free. As it happens, none of them have any resemblance to your proposed design. RabbitMQ has been benchmarked[1] to 1 million messages/sec on 30 servers and works very well for many people. Why no…
This benchmark is indeed very interesting. I think I may have failed to express my point, though. I'm not building a message queue, as it is certainly a very hard problem that has been engineered for years by people way smarter than me :) I'm merely leveraging the goodness of their implementations (in my case redis, but RabbitMQ is also an option I've considered explicitly in my post). The chat is a contrived example…
If you're building a large scale chat service you are implicitly also building a message queue.
And as for the high load you haven't actually experienced high load until you put this into production with a million users.
To make that clearer: you can design a system for any number of users, the only relevant question is how it held up in practice and as long as you haven't had a million concurrent users you just don't know (and probably it won't).
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#16Earlier quoted context omitted.
Feedback? How about just not making wild claims about byzantine fantasy designs that you never tested under any kind of load. There has been a lot of research in messaging architectures, some of the best message brokers are free. As it happens, none of them have any resemblance to your proposed design. RabbitMQ has been benchmarked[1] to 1 million messages/sec on 30 servers and works very well for many people. Why no…
This benchmark is indeed very interesting. I think I may have failed to express my point, though. I'm not building a message queue, as it is certainly a very hard problem that has been engineered for years by people way smarter than me :) I'm merely leveraging the goodness of their implementations (in my case redis, but RabbitMQ is also an option I've considered explicitly in my post). The chat is a contrived example…
I'm not building a message queue
That may be the kernel of the problem here; you built a subset of a message queue without realising it.
RabbitMQ has a websocket plugin[1]. Just make your javascript connect directly to a RabbitMQ cluster and you have a solid, scalable foundation - almost for free.
[1] http://www.rabbitmq.com/blog/2012/05/14/introducing-rabbitmq...
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#17GameRanger has six million users, tens of thousands to hundreds of thousands of whom will be active simultaneously. His chat problem involved has moderate fan-out.
Scott Kevill does it on a single machine (last time I checked) with hand-rolled C++ and close attention to the details of how the Linux networking stack works.
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#18Earlier quoted context omitted.
Oh, you're absolutely right, 10M/s is a mistake, which I've corrected. Few remarks though: - it's still way below the number of actions we're talking about here (~100k/s) - since redis is only used as a generic MQ and not as a store, it can be sharded at the app level without the pain usually associated with redis clustering - I've deployed a similar (but less performant) design for the player of a gaming website, wh…
Feedback? How about just not making wild claims about byzantine fantasy designs that you never tested under any kind of load. There has been a lot of research in messaging architectures, some of the best message brokers are free. As it happens, none of them have any resemblance to your proposed design. RabbitMQ has been benchmarked[1] to 1 million messages/sec on 30 servers and works very well for many people. Why no…
I was under the impression that the design was indeed never tested, but at least the author had some real life experience of building a moderately sized chat service.
I can understand why people like you are pissed by this kind of blog post which reads a bit too much like an ad, but i think it's still good that people are trying to reinvent the wheel with completely new technologies, because sometimes it leads to surprising results.
Maybe the OP should add some warnings in the blog, saying that it's an highly experimental design that people shouldn't try to use for their own projects at the moment...
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#19Earlier quoted context omitted.
but has this design been implemented to effectively handle something close to a million users Obviously not. Some of his numbers are off by an order of magnitude. E.g. he claims "10 million messages/sec" for a single redis instance. In reality redis tops out at well under one million messages/sec; http://redis.io/topics/benchmarks The design is almost comically bad (single source of truth for a "scalable" chat app?!)…
Oh, you're absolutely right, 10M/s is a mistake, which I've corrected. Few remarks though: - it's still way below the number of actions we're talking about here (~100k/s) - since redis is only used as a generic MQ and not as a store, it can be sharded at the app level without the pain usually associated with redis clustering - I've deployed a similar (but less performant) design for the player of a gaming website, wh…
Have you ever used redis MQ at scale? I'm guessing no; the redis server is not your bottleneck. The fact that every server proc has to parse every message puts a hard ceiling on the amount of traffic you can handle. Intelligent routing is, I believe, the answer here. I've spoken with antirez on this and he agrees that at the scales you're talking about, redis MQ doesn't cut it.
Re: Million User Webchat with Full Stack Flux, React, Redis and PostgreSQL
#20Great post, but has this design been implemented to effectively handle something close to a million users ( or even 100k and show that no part is overheating) ? As in every new and complicated design, i'm a bit skeptical of rules of thumb calculations. You never know what the wrong latency issue at the wrong place can do...
but has this design been implemented to effectively handle something close to a million users Obviously not. Some of his numbers are off by an order of magnitude. E.g. he claims "10 million messages/sec" for a single redis instance. In reality redis tops out at well under one million messages/sec; http://redis.io/topics/benchmarks The design is almost comically bad (single source of truth for a "scalable" chat app?!)…
I agree. "Number of messages a single Node broker can handle: ~10k per second without JSON stringification memoization, ~100k per second with JSON stringification memoization (Nexus Flux socket.io does that for you)." <- Can't be possible. The numbers should be lower with JSON stringification/parsing instead of being 10x.