Could it be that the numbers with EMQX are slightly lower due to rate limiting or overload protection in general? I'm asking this because, in my project, I'm considering EMQX for its capabilities in the industry.
Could it be that the numbers with EMQX are slightly lower due to rate limiting or overload protection in general? I'm asking this because, in my project, I'm considering EMQX for its capabilities in the industry. Edit: Also... In our application paid features would be inevitable. So, Is it correct to assume that upscaling (paid) would make this difference in performance insignificant?
In terms of overload protection: for FlashMQ it wasn't an overload to begin with. The test shows the actual CPU and memory requirements for the servers in question. That will not be reduced when you buy a paid license.
Impressive... I was looking for current open source MQTT brokers to use in a home automation project so I don't really need the scalability but saving compute resources is always a good idea. Is FlashMQ also suitable for small projects?
Yeah, for sure. It takes virtually no time configure and it starts up in 100 ms. But, under those conditions it can also easily do millions of clients, so it actually does offer scalability, I'd say.
@@flashmq for EMQX and Mosquitto there is everything - where is the config, which parameters doing what etc. - you know: the manual, installation guide etc. ;-)
@@zyghom That's exactly that the 'manual page' describes? Plus, the download page should be clear enough how to install? Additionally, there is 'flashmq --help'?
Just installed EMQX like an hour ago. Revelling in self achievement, admiring the dashboard with all its stats, feeling self empowered by quick and easy ACL control, then watched this. Now devastated, disillusioned, humbled and heartbroken....
@@flashmq My dilemma is my client wants a management dashboard for everything. I installed mosquitto for them already. But eyes start rolling as soon as I open a terminal to manage permissions. They say don't want a "black-box" they can't administer themselves. I'm definitely going to try out FlashMQ for myself though. ;)
I can understand that. A side project that I welcome anyone to start, is a dashboard like that. A webapp and a C++ plugin are 'all' that is required. It would be a separate project easily integrated, yet not be hard-coupled to each other, so easy to deal with.
Without looking it up, it was probably an Amazon m5.xlarge. The video shows it has 16 GB of RAM and four cores. m5 series are Xeon Platinum 8000 series. But, I don't know for sure anymore...
@@JohanRomero I understand the wish. However, when clustered, MQTT servers need to be aware of each other to act as one logical server. As it stands, FlashMQ doesn't support that. However, when it comes to fail over; in practice one machine at something like Amazon EC2 will have a very high uptime, and itself be quickly restarted in the event of failures. I always recommend people really reconsider their high-availability requirement, because complex setups like can be less reliable than just one server, and people may try to solve problems that will hardly occur.
This benchmark didn't have much more than the load simulator you can download at www.flashmq.org/download/mqtt-load-simulator/. The script was just one line, so that I didn't have to type the arguments.
I would be very interested to see how it would handle a lot of clients subscribing to a few dozens of topics within a few millions with retained messages (ie: how good is the indexing and querying of retained messages)
I recently optimized handling of large volumes of retained messages. If you could be a bit more specific about your use case, perhaps I can write a blog post with some benchmarks. To be precise: a few dozen topics can only have a few dozen retained messages: it's a set value per topic. So which metric numbers in the millions?
@@flashmq the idea is to use topics as paths to entities like in REST. So subscribing to the topic "path/to/entities/{id}" will immediately give you the last known state of the entity (as a retained message) and then any update as it happen (also retained messages that will replace the older ones). The number of entities could grow to a few millions and each user would subscribe to a few dozen max at any given time (no more than what could be displayed on the user's screen)
I think it can handle that, with my recent optimization. I was indeed testing with millions of retained messages. Do you have a message publish volume in mind? Perhaps I could make a short video doing a demo.
@@flashmq My use case doesn't require a sustained volume of messages so it wouldn't be a good benchmark. I think a good benchmark would be how fast can you add subscriptions to topics with retained message (either fully qualified topic subscriptions or patterned). This would demonstrate the efficiency of the querying of retained messages index. A second benchmark would be to produce a lot of retained messages on different topics (with each topic receiving multiple retained messages during the test) to test the building/maintaining of retained messages index.
Could it be that the numbers with EMQX are slightly lower due to rate limiting or overload protection in general? I'm asking this because, in my project, I'm considering EMQX for its capabilities in the industry.
Why is EMQX so bad if they claim its the most scalable ?
Could it be that the numbers with EMQX are slightly lower due to rate limiting or overload protection in general? I'm asking this because, in my project, I'm considering EMQX for its capabilities in the industry.
Edit: Also... In our application paid features would be inevitable. So, Is it correct to assume that upscaling (paid) would make this difference in performance insignificant?
In terms of overload protection: for FlashMQ it wasn't an overload to begin with. The test shows the actual CPU and memory requirements for the servers in question. That will not be reduced when you buy a paid license.
How does mosquitto fare?
It's single-threaded, so doesn't scale. And it has problems dealing with many (inactive) clients.
I'm sure emitter can reach half message through put of what flashmq capable of.
Very clear and informative video!
Impressive...
I was looking for current open source MQTT brokers to use in a home automation project so I don't really need the scalability but saving compute resources is always a good idea.
Is FlashMQ also suitable for small projects?
Yeah, for sure. It takes virtually no time configure and it starts up in 100 ms. But, under those conditions it can also easily do millions of clients, so it actually does offer scalability, I'd say.
man, I JUST installed EMQX - should I ry FlashMQ then? ;-)
ups, there is virtually NO DOCUMENTATION on your page, nothing except man pages ;-(
It's free, as in free speech and beer, so sure, give it a try. As for documentation, what else did you want to read?
@@flashmq for EMQX and Mosquitto there is everything - where is the config, which parameters doing what etc. - you know: the manual, installation guide etc. ;-)
@@zyghom That's exactly that the 'manual page' describes? Plus, the download page should be clear enough how to install? Additionally, there is 'flashmq --help'?
Any idea of why flashmq is so performant?
Well, no layers that cause runtime overhead (library or language), in-line assembly, etc. See www.flashmq.org/about/
Just installed EMQX like an hour ago. Revelling in self achievement, admiring the dashboard with all its stats, feeling self empowered by quick and easy ACL control, then watched this. Now devastated, disillusioned, humbled and heartbroken....
Ha, well, I encourage you to evaluate all the tools for your needs and choose the correct one. There won't be one that is best at everything.
@@flashmq My dilemma is my client wants a management dashboard for everything. I installed mosquitto for them already. But eyes start rolling as soon as I open a terminal to manage permissions. They say don't want a "black-box" they can't administer themselves. I'm definitely going to try out FlashMQ for myself though. ;)
I can understand that. A side project that I welcome anyone to start, is a dashboard like that. A webapp and a C++ plugin are 'all' that is required. It would be a separate project easily integrated, yet not be hard-coupled to each other, so easy to deal with.
Awesome! What are the server specs?
Without looking it up, it was probably an Amazon m5.xlarge. The video shows it has 16 GB of RAM and four cores. m5 series are Xeon Platinum 8000 series.
But, I don't know for sure anymore...
there is any documentation on how to deploy FlashMQ with Kubernetes for autoscale?
There is no cluster support (yet?). Are you looking to have more than a few million clients? If not, one server ought to do it.
@@flashmq I would like to distribute the load across multiple servers, not only for scabilibity but for redundancy and fail over.
@@JohanRomero I understand the wish. However, when clustered, MQTT servers need to be aware of each other to act as one logical server. As it stands, FlashMQ doesn't support that. However, when it comes to fail over; in practice one machine at something like Amazon EC2 will have a very high uptime, and itself be quickly restarted in the event of failures. I always recommend people really reconsider their high-availability requirement, because complex setups like can be less reliable than just one server, and people may try to solve problems that will hardly occur.
@@flashmq Well EMQX can scale horizontally right?
Yes, EMQX can, but the costs of running five to ten servers what FlashMQ can do with one it to be considered.
Where could we get the scripts to actually test ourselves?
This benchmark didn't have much more than the load simulator you can download at www.flashmq.org/download/mqtt-load-simulator/. The script was just one line, so that I didn't have to type the arguments.
@@flashmq Thank you so much for the swift response :D
I would be very interested to see how it would handle a lot of clients subscribing to a few dozens of topics within a few millions with retained messages (ie: how good is the indexing and querying of retained messages)
I recently optimized handling of large volumes of retained messages. If you could be a bit more specific about your use case, perhaps I can write a blog post with some benchmarks. To be precise: a few dozen topics can only have a few dozen retained messages: it's a set value per topic. So which metric numbers in the millions?
@@flashmq the idea is to use topics as paths to entities like in REST. So subscribing to the topic "path/to/entities/{id}" will immediately give you the last known state of the entity (as a retained message) and then any update as it happen (also retained messages that will replace the older ones). The number of entities could grow to a few millions and each user would subscribe to a few dozen max at any given time (no more than what could be displayed on the user's screen)
I think it can handle that, with my recent optimization. I was indeed testing with millions of retained messages.
Do you have a message publish volume in mind? Perhaps I could make a short video doing a demo.
@@flashmq My use case doesn't require a sustained volume of messages so it wouldn't be a good benchmark. I think a good benchmark would be how fast can you add subscriptions to topics with retained message (either fully qualified topic subscriptions or patterned). This would demonstrate the efficiency of the querying of retained messages index. A second benchmark would be to produce a lot of retained messages on different topics (with each topic receiving multiple retained messages during the test) to test the building/maintaining of retained messages index.